-
Notifications
You must be signed in to change notification settings - Fork 2.1k
fix: use alias for versioned lambda functions #6767
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
base: dev
Are you sure you want to change the base?
Changes from all commits
0e3e96d
207829d
0a7d668
5f2231e
1e105c1
6cf7667
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -272,7 +272,12 @@ export interface WorkflowArgs | |
| * ID generation inside durable operations like `ctx.step()`. | ||
| * | ||
| * :::caution | ||
| * Workflow handlers have versioning enabled. Deploying an update won't update existing running workflows. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we should keep the versioned behaviour. i don't understand why we changed this
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @vimtor The versioned behavior is unchanged. The main reason durable workflows version the handler is so that an in-flight execution resumes on the same code it started on. That's preserved: the lanbda API captures the resolved version at execution start and pins all resumes/retries to that captured version, regardless of whether the alias is later moved. What the alias buys us, beyond what a pinned numeric version gives, is decoupling the handler identity from the deployed version. If you ship a bad release and need to roll back, you just point the alias at the previous version, and no consumers have to be updated. Any newly-started executions immediately run against the rolled-back version. With a pinned It also opens the door to weighted aliases: you can split traffic across two versions of a workflow handler for A/B tests or canary rollouts without touching any client. None of that is possible if consumers point at a specific numeric version. The doc rewrite just makes the mechanism explicit and adds the |
||
| * The workflow SDK invokes the handler through an alias. Each execution is pinned | ||
| * to the version the alias points to when it starts, and stays pinned across resumes | ||
| * and retries — so deploying an update won't affect already-running workflows. | ||
| * | ||
| * To resume on the latest code, invoke the function directly via the Lambda SDK | ||
| * with the `$LATEST` qualifier. Not recommended for production. | ||
| * ::: | ||
| * | ||
| * Before using workflows in production, review the | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can also define versioning with
versioning: trueThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vimtor
fn.publishis the resolved truth on the underlyingaws.lambda.Function. Upstream at function.ts:2659, it's set toargs.versioning || Boolean(args.durable), so checkingfn.publishcovers both paths in one expression