1 client snapshot staging and repair receipts
forgejo-actions edited this page 2026-07-13 19:45:35 +00:00

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.