Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix reuse of pipelines including IterBlock #84

Closed
wants to merge 1 commit into from

Conversation

russellb
Copy link
Member

@russellb russellb commented Jul 4, 2024

When running sdg.generate() more than once, a pipeline including an
IterBlock would fail because the block_kwargs were removed the
first time the block was used. This change removes the special
handling for IterBlock because it does not appear to be necessary.

The new code ends up calling the block's constructor with all of the
same arguments, but now block_kwargs doesn't disappear.

Signed-off-by: Russell Bryant [email protected]

@mergify mergify bot added the ci-failure label Jul 4, 2024
When running `sdg.generate()` more than once, a pipeline including an
`IterBlock` would fail because the `block_kwargs` were removed the
first time the block was used. This change removes the special
handling for `IterBlock` because it does not appear to be necessary.

The new code ends up calling the block's constructor with all of the
same arguments, but now `block_kwargs` doesn't disappear.

Signed-off-by: Russell Bryant <[email protected]>
@russellb russellb force-pushed the fix-iterblock-reuse branch from 51ffecf to fd3cc02 Compare July 4, 2024 02:58
@mergify mergify bot removed the ci-failure label Jul 4, 2024
@markmc
Copy link
Contributor

markmc commented Jul 4, 2024

You've also fixed the fact that we were instantiating the blocks twice:

     block = block_type(**block_config)
     if block_type == IterBlock:
         ...
     else:
         block = block_type(**block_config)

I did wonder about this special handling of IterBlock, but it's all confusing enough I couldn't quickly convince myself that it wasn't needed. I sort of looks like a leftover from an earlier implementation where the IterBlock's config just got passed down to the LLMBlock with block_kwargs added? Or something

Anyhow, lgtm 👍

@markmc
Copy link
Contributor

markmc commented Jul 5, 2024

Some special handling of IterBlock turns out to be needed in #86 ... so #86 should replace this PR, at least how it's currently implemented

@russellb russellb marked this pull request as draft July 7, 2024 03:18
@russellb
Copy link
Member Author

russellb commented Jul 7, 2024

Some special handling of IterBlock turns out to be needed in #86 ... so #86 should replace this PR, at least how it's currently implemented

marked this as a draft while we work through #86. This will help remind me to come back around and check if it's still relevant later.

@markmc
Copy link
Contributor

markmc commented Jul 11, 2024

IterBlock was removed by #105

@markmc markmc closed this Jul 11, 2024
jwm4 pushed a commit to jwm4/sdg that referenced this pull request Dec 13, 2024
…actions/step-security/harden-runner-2.8.1

Bump step-security/harden-runner from 2.8.0 to 2.8.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants