Interrupt and Resume — Patterns

Stop only where it is safe to stop

Problem. Honouring a stop request immediately means stopping at an arbitrary instruction — possibly after a request was sent but before its result was recorded — which is precisely the state that cannot be resumed correctly.

Approach. Declare safe points, normally the boundary between iterations or steps, and make a stop request a flag that is honoured at the next one. Record that an interrupt is pending so the user sees it was received, and bound how long a step may run before a stop can take effect.

Trade-off. Responsiveness is limited by the longest step, which may be minutes, and users pressing stop twice must be handled. The alternative — stopping anywhere — requires continuation capture that most runtimes cannot provide honestly.

Consult the effect ledger on resumption

Problem. A snapshot that records attempted steps cannot tell a continuation whether the email was actually sent. Resuming on the basis of intent re-performs effects; resuming on the assumption they completed skips ones that failed.

Approach. Record each external effect at the moment it is applied, keyed by a deterministic identifier derived from the run and the call, with its outcome. On resumption, consult the ledger before any step that might repeat an effect and skip what is recorded as applied. Mark effects whose outcome is genuinely unknown as requiring explicit reconciliation rather than guessing.

Trade-off. Every effect-performing tool must participate, and tools that cannot produce a stable key must be declared unsafe to resume past. The unknown-outcome bucket is real and needs an owner, which is work that only pays off during incidents.

Revalidate assumptions before continuing

Problem. A run paused for four hours resumes into a world that moved: the price changed, the record was edited, the credential expired, the approval was superseded. Continuing without checking produces confident action on stale premises.

Approach. Record, with the snapshot, the facts the remainder depends on and how to re-check them. On resumption, re-check them before the first action, and treat a contradiction as a reason to re-plan or to return to the user rather than to proceed. Make credential refresh part of resumption rather than something discovered by a failing call.

Trade-off. Revalidation costs calls and latency at exactly the moment a user is waiting to see progress. It also requires facts to be stated explicitly, and anything left unstated is still assumed silently.

Suspended runs expire

Problem. A pause with no deadline is a resource leak with a human-shaped excuse. Runs accumulate holding claims, reserved budget, and personal data, and the oldest ones are waiting for people who have left the company.

Approach. Give every suspended run a deadline at the moment it suspends, chosen from the reason for the pause rather than a global default. On expiry, move it to a terminal state with a distinct reason, release its claims, notify whoever was waiting, and keep the snapshot long enough for someone to restart deliberately if they want to.

Trade-off. Deadlines will sometimes expire runs people genuinely intended to resume, and the expiry period for approval waits is a product decision rather than a technical one. Restart-from-snapshot must therefore actually work, which is a second path to maintain.