What happens when you update a step/workflow code while they’re still running

[MendyLanda]

Say I have a workflow that runs for 2 months.

It's live in prod, and we have running workflows already.

What happens when I make changes to one of its steps, or to the workflow itself?

[brad-decker]

Very interested in hearing the answer to this. I think this determines whether we can rely on workflow in production. If I use this to handle my analytics queue and make code changes, what rules must I follow to ensure my queued events and workflows continue to run after deployment? In addition, do they run on the old code branches, meaning that if I notice a bug in my workflow that I cannot fix, it will prevent queued events from encountering it, or does it somehow magically run on the new code?

[pranaygp]

May 2026 update - we added a fundamental docs page for versioning in workflows: https://workflow-sdk.dev/docs/foundations/versioning and will continue to post updates there as thinking evolves on versioning (which differs somewhat from the initial thinking in the older answer below).

---

Runs are tied to a specific deployment. So, if you deploy a new version, existing runs continue running on whatever deployment they were triggered on. Changes to steps and workflow code won't affect them.

So, if you do make a code change (let's say to fix a bug), you would deploy a new version. New runs will start to run on the latest version. You will then be able to use the CLI (or the web UI packaged with the CLI, or the Vercel Dashboard) to "upgrade" runs from the old version to the new version.

Upgrading can mean two things

1. "Cancel and restart" (simplest) - i.e. this will ignore whatever progress the workflow made and will simply cancel the current run and restart from scratch on the new workflow, as long as the input type signature to the updated workflow hasn't changed
2. "Cancel and resume" - i.e. this will cancel the current workflow, but "carry over" the event log to the new version so we can replay exactly where you left off. To pull this off, we need to "dry run" the event log against the target version you need to upgrade to ensure it's compatible. If the target workflow has changed in a way that would cause the upgrade to be incompatible, we would warn you right away and just let you know.

There's a lot that can be built on top of this to get the DX right (its's a hard challenge) - but that's essentially the idea

---

Understandably, this implementation works best with worlds that support serverless runtimes and can keep old versions around (Vercel, for example). For serverfull runtimes that can't do version pinning, we will need to find an alternate solution that works well.

[MendyLanda]

"Cancel and resume" absolutely incredible that this works!

[albertocubeddu]

This is a game changer... !!

What if we want to make workflows dynamic; So customers can build their own workflows that automatically trigger based on events? And when they change them, only the new one will be abiding the new rules!!!!

I haven't seen anything to create a dynamic one (e.g. starting from a JSON Schema) is this already possible or is in the roadmap?

If you have it, i would be more than happy to wait and implement the whole orchestration with Vercel and Next!

[pranaygp]

@albertocubeddu yeah we're shipping a workflow builder template soon for dynamic user workflows built on top of workflow, and there's a lot of interesting stuff planned down the line to natively support that use case in the framework

It'll need to play well with this versioning spec too I described - will keep cooking on this

[shirmanov]

@pranaygp According to the current implementation, what would happen if I have several workflow runs waiting on hooks (or sleep) and I shutdown the server process, modify the workflow (or its steps) and launch the server again, call the hooks to resume workflows specifying remembered ids? thus no previous workflow version running, only the new one.

[pranaygp]

hooks are registered for the lifecycle of the run - so until a run ends or explicitly disposes a hook, the hook doesn't end. if you "shut down the worker" and restart it, it will redrive itself to resume any inflight hooks/sleeps and continue to process (and potentially complete and dispose those hooks based on the logic in your workflow)

that's the promise of durable workflows - they survive client side server restarts since the state is stored in a database

[joaom182]

I don't see where in the Vercel UI or Web UI (locally) we can cancel and resume (to upgrade) a workflow.

[jamipouchi]

Any news on this @pranaygp ? I don't see how we could cancel and restart nor cancel and resume from vercel nor the cli.

Without this, long-running workflows are very tedious as when we want to have an update we need to manually cancel and then restart 1 by 1, which is also not atomic and can lead to some missed work

[pranaygp]

cancel and restart is supported via the CLI and web UI. You can do thes per run, or do them in batch by selecting multiple runs and hitting "cancel" and/or "rerun on latest"

Also just added more docs here

https://workflow-sdk.dev/v5/docs/foundations/versioning