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]

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