04 / Work state
The worker can stop. The work can continue.
A new worker can continue from a saved record.
What the teams report
Shopify keeps the session record in Postgres. A worker can stop, and a new worker can read the same history. The session keeps its identity. [1]
Sentry’s Junior pauses before a serverless timeout. It places a continuation task in a queue so another run can continue the work. [2]
Sierra uses checkpoints and ordered events to restore a runner after it stops for a period of inactivity. [3]
“Cells die, sandboxes die, machines die. The conversation doesn't.”
Shopify, on session survival. [1]
The saved record exists outside the worker.
Our observation
A saved record needs a clear scope
A conversation, a file, and an action in another system are different kinds of state. Each needs a defined recovery method.
Conversation history alone does not establish which actions completed. A recovery design also needs to account for work already done.
These cases show ways to continue a task. They do not establish that every file or action survives every failure.
A question for your buildWhat must the next worker know before it can continue?
Sources
- Shopify: Under the RiverThe session record and disposable workers.
- Sentry: Building an internPauses and continuation tasks before timeouts.
- Sierra: AgencyCheckpoints and event replay after inactivity.