Support closure variables for serialized step functions #366
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: a431eb2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Nov 19, 2025
Member
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
VaguelySerious
approved these changes
Nov 25, 2025
| Object.defineProperty(wrappedStepFn, 'name', { | ||
| value: stepFn.name, | ||
| }); | ||
| Object.defineProperty(wrappedStepFn, 'stepId', { |
Member
There was a problem hiding this comment.
I'd prefer if we renamed stepId in this PR to stepName or similar to avoid future confusion with actual stepIDs like step_<ulid>
Member
Author
There was a problem hiding this comment.
That's fair. I named it as such here to be analogous to the workflowId property which follows the similar string format.
stepName/workflowName is perhaps less ambiguous, but in actuality the string contains both a filename and the step/workflow name. I wonder if we can pick a name that properly encompasses both pieces of information (location?). Anyways, if we do change the name let's do for both step+workflow in a separate PR.
Member
Author
Merge activity
|
TooTallNate
force-pushed
the
factory-with-step-method
branch
from
7e5fe40 to
40ab768
Compare
TooTallNate
force-pushed
the
11-19-support_closure_variables_for_serialized_step_functions
branch
from
2854b16 to
247fa49
Compare
TooTallNate
changed the base branch from
factory-with-step-method
to
graphite-base/366
TooTallNate
force-pushed
the
11-19-support_closure_variables_for_serialized_step_functions
branch
from
247fa49 to
a431eb2
Compare
TooTallNate
deleted the
11-19-support_closure_variables_for_serialized_step_functions
branch
adriandlam
pushed a commit
that referenced
this pull request
Nov 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added support for closure variables in serialized step functions, allowing step functions to access variables from their lexical scope when executed remotely.
What changed?
StepFunctionreducer to capture and serialize closure variablesStepFunctionreviver to restore closure variables in the execution contextWhy make this change?
Previously, serialized step functions could only access their arguments when executed remotely, but not variables from their lexical scope. This limitation made it difficult to write reusable step functions that needed to access shared configuration or context. This change enables more natural programming patterns by allowing step functions to access closure variables, making the code more intuitive and reducing the need to pass all context as function arguments.