A dropped link is not a lost document
Connections fail: a laptop sleeps, a tunnel closes, a phone walks out of signal. The question is never whether it happens but what state you come back to. watershed reconnects the transport, remaps the client id, and resubmits pending operations against the server’s current reference sequence number before live delivery resumes.
Rehydrate from a summary
A long-lived document accumulates thousands of ops. Replaying all of them
on every join would make reconnection slower the older the document got.
An application can explicitly call summarize(document) to
write the client’s current confirmed channel snapshots to floodgate storage.
The server records the sequence number covered by that summary. On a later
bootstrap, watershed loads an available summary and applies operations
after that point.
Every channel knows how to serialise and rebuild itself this way, so the snapshot is not a lossy cache: it is the converged state, exactly, plus the metadata each structure needs to keep its merge rule honest. An OR-set's add tags and a 2P-set's tombstones travel in the summary, so add-wins and permanent-removal semantics survive a reload intact.
Summary when available, history when not
A fresh bootstrap does not require a summary. If the server provides one, the runtime seeds channels from it and replays the supplied tail. Without one, it starts empty and replays the retained initial messages. If that batch begins after a missing prefix, the runtime pages the gap from the deltas endpoint before declaring the document ready.
Kernel demos also exercise from_summary directly by building
baseline replicas under a dedicated survey-baseline
identity. That validates channel snapshot decoding, but it is not the
transport reconnect path. Because required sequence metadata rides along
in snapshots,
order-sensitive structures like claims
stay correct after a load: a slot that was claimed before you dropped is
still claimed when you return, and a compare-and-set still refers to the
right prior state.
Reconnect is a resync, not a reset. You do not lose the document and you do not fork a divergent copy. Pending durable operations are resubmitted and confirmed history catches the runtime up. Ephemeral signals are the exception by design: a ripple broadcast while you were gone is not in any summary and will not replay, which is exactly right for a cursor and exactly why durable state belongs in a channel.
Summaries are explicit checkpoints, not a requirement. Bootstrap uses one when available and otherwise replays retained history; reconnect preserves pending durable operations by resubmitting them against the resumed session.