Skip to content

Continuation Token

Resumable-state artifact — instantiates Definition-Time Context Binding

An opaque, tamper-evident token carrying the minimum state needed to resume a computation exactly where it paused, whoever later presents it.

A Continuation Token freezes "where I am" in a computation into a small, self-contained, opaque handle, so the work can be picked up later — by a different request, a different server, or a different client session — from exactly the point it left off. It captures a position, not a whole environment: the cursor into a stream, the offset in a long job, the "rest of the work" still to do. Its defining move is that the token is holder-independent and self-describing — it carries its own resume state so the server need not remember the paused caller, and it is opaque and tamper-evident so the state cannot be read, forged, or fast-forwarded by whoever holds it. That is what separates it from a general serialized closure: it is a minimal, sealed bookmark, not a shipped function-plus-environment.

Example

A search API returns results a page at a time. Rather than keep a per-client scroll session alive in memory — fragile, stateful, and doomed the moment a client disappears — each response includes a next token. That token is the resume point: it encodes where in the result set the next page begins, sealed so the client cannot decode it, hand-edit an offset, or skip ahead into results it should not see. The client stores nothing but the token; to continue, it simply presents it, and any server in the pool can resume the traversal because everything needed is inside the token. When the client stops paging, the token quietly expires and the resume state it stood for is disposed. A resumable file upload uses the same shape: an upload token that says "you have sent bytes 0–5 MB, continue from here," valid for a bounded window and then gone.

How it works

  • Reify the resume point. Fold the minimal continuation — position, phase, and any small carried values — into the token itself, so no paused state lives on the server.
  • Seal it. Make the token opaque and integrity-protected, so a holder can present it but cannot read, forge, or advance it beyond what the issuer sanctioned.
  • Time-box it. Bind a lifetime to the token; when it expires or the work completes, the resume state it represents is disposed rather than lingering.

Tuning parameters

  • State inline vs. by-reference — carry the resume state in the token, or carry an opaque key that points to server-side state. Inline is stateless and scalable; by-reference keeps tokens tiny but re-introduces server memory.
  • Opacity level — fully sealed, or a readable-but-signed structure. Sealing hides internals (so clients cannot depend on them) at the cost of debuggability.
  • Lifetime — how long a token stays resumable before expiry. Longer windows are friendlier to slow clients but widen the replay and staleness surface.
  • Single-use vs. reusable — whether presenting a token consumes it. Single-use blocks replay and double-advance; reusable is simpler but weaker.

When it helps, and when it misleads

Its strength is decoupling who paused from what can resume: because the token carries its own minimal state, the server stays stateless and horizontally scalable, and the work survives client crashes and load-balancer reshuffles. In spirit it is a reified continuation — the "rest of the computation" made into a value you can hand around.[1] The honest failure mode is that a token is only as safe as its seal and its clock: a non-opaque token invites clients to reverse-engineer and depend on its internals (freezing your implementation) or to tamper with the position, and a token with no expiry becomes a stale, replayable key long after its context is valid. The classic misuse is stuffing sensitive or authorizing data into the token and treating possession as proof of permission rather than merely of position. The discipline is to keep tokens opaque, signed, minimal, and time-boxed — and to source any authority to resume from a capability, not from the token's mere existence.

How it implements the components

  • captured_environment_manifest — the token is the manifest of the resume state: the minimal position-and-carried-values needed to continue.
  • context_integrity_signature — it is sealed and integrity-protected, so its captured state cannot be forged or advanced by a holder.
  • context_retention_and_disposal_rule — its bound lifetime governs how long the resume state persists and when it is disposed.

It carries state to resume but not the general code-plus-environment transport that is Closure Serialization, and its possession is not authority to act — that separation belongs to Capability Object.

References

[1] In continuation-passing style, a continuation is an explicit value standing for "the rest of the computation." A continuation token is that idea made durable and transportable — a reified resume point handed to a client instead of held on a call stack. ↩