How a run meets new code
On each call, your workflow runs from the top, and each step looks for its saved result by kind and name, in the order your code reaches it. So what matters is the name of each step, not where it sits in your code:- A step that keeps its name gives back its saved result, even if you moved it.
- A step with a new name runs as a new step, even where an old one used to be.
- A saved step your code no longer reaches is ignored.
Changes that are always safe
- Changing what happens after the point a run has reached. Its next call runs the new code from there.
- Changing the code inside a step that’s already saved. The saved result comes back, and the new code runs only in runs that haven’t reached the step yet.
- Adding steps after the point a run has reached.
- Changing code outside steps, as long as it takes the same path for the steps already saved.
Changes to make with care
Adding a step before the point a run has reached
The step runs at the run’s next call, since it has no saved result. For example, an email added between two steps of a run that has already passed that point goes out when the run picks up. That’s often what you want. If it isn’t, branch on a version, as shown below.Renaming a step
The renamed step has no saved result, so its work is done again under the new name. Keep the old name for steps that have already run in some runs.Changing a sleep’s duration or a wait’s key
A sleep is named after its duration, and a wait after its key. A run already sleeping keeps its original wake-up time, and a run already waiting keeps its original key. Once it goes on, the new name doesn’t match the saved one, so the run pauses again with the new duration or key. To wake a run that’s already waiting, emit the event with its original key.Removing steps that share a name
Steps with the same name are matched in order. If you remove one of them, the ones after it shift, and each gets the saved result of the one before it.Keep old runs on the old path
When a change must only apply to new runs, branch on a version saved in the run’s first step. Add the step when you first write the workflow, returning1. When a change comes, return the next number and branch on it:
1, so they keep the old path. New runs save 2 and take the new one.