Client Snapshot Staging And Repair Receipts
Client snapshot staging buffers server snapshots by id, applies them after reorder grace, and emits repair receipts when gaps persist.
How It Works
Incoming snapshots enter a staging window keyed by snapshot_id. Ready snapshots flush after the buffer delay. If a gap remains beyond reorder grace, the client reports missing ids through snapshot receipt and repair requests. A ready full-sync baseline can rebase state and make older deltas irrelevant.
How To Use It
When changing snapshot reducers, keep staging and repair receipt behavior in mind. Deltas must be safe to skip when a newer full sync is ready. Receipt shapes must only report gaps the client has actually observed and waited on.
Use staging tests when changing AOI replication, reducer ordering, or full-sync behavior.
Invariants
Snapshot ids must be monotonic. Duplicate and stale snapshots should not apply twice. Missing ids should wait through reorder grace before repair. Full-sync baselines must be preferred over unsafe delta application.
Debugging
Late bootstrap snapshots, stale duplicates, missing full sync, and permanent resync waits are the common failure modes. Inspect buffered ids, last applied id, missing receipt ids, and repair timing before changing server replication.
Examples
If snapshot 12 arrives before 11, the client buffers 12 until 11 arrives or reorder grace expires. If a full sync for 15 becomes ready first, the client can rebaseline and skip unsafe older deltas.