What should a process that may run for months remember?

Why it matters

When a workflow waits for weeks, the world around it changes: new code is deployed, a rule is modified, someone changes job. The process has to decide whether it carries on with the conditions of back then or with those of now.

Keeping everything is expensive and makes any migration fragile. Keeping little turns every resumption into a reconstruction by hand.

What we know so far

We have ended up separating three things. The business data, versioned and with an explicit schema, because that is what migrates. The position within the journey, which has to be mappable when the shape of the workflow graph changes. And the history of intermediate decisions, which we keep as a record of events rather than as state: it is never migrated, only read.

The distinction between the last two is the one that has served us best. The position says where to carry on; the history says why the process got there. Confusing them produces enormous states that nobody dares touch.

One more thing, learned the expensive way: every wait needs an explicit expiry from day one. A process that waits indefinitely does not fail, which is exactly the problem.

What remains open

We have no clear rule for when a waiting process should be abandoned rather than resumed under rules that are no longer its own.

Nor do we know how to migrate live processes when the shape of the workflow graph itself changes.