Replay is a recovery mechanism with a boundary
A stream can expose a starting slot without storing an unlimited archive. Recovery depends on the server's current replay window, the subscription type and its filters. Keep your checkpoint in durable storage and measure the outage in the same units as the replay capability.
A recovery state machine
checkpoint = last_durably_committed_slot()
subscribe(from_slot=checkpoint, filters=desired_filters)
for update in stream:
persist_idempotently(update)
advance_checkpoint_after_commit(update.slot)This is Yellowstone-style pseudocode. Resuming at the saved slot creates intentional overlap. Slot alone is not a unique event ID; deduplicate transactions by signature and account updates by their documented update identity.
Plan the fallback before an outage
- Save filters and commitment alongside the checkpoint.
- Check whether the checkpoint remains inside the replay window before treating recovery as complete.
- If replay is rejected or too old, use a suitable RPC history or indexed dataset for the missing application records.
- Join replay and live output through one deduplication path, then verify continuity.
Supanode's current scope
Supanode provides a 100-slot gRPC replay window and two days of RPC history. These are different products and units. They do not establish a two-day gRPC buffer or a universal SQL retention period. Use the current product Docs for the applicable interface and plan details. If your gap exceeds the available recovery window, retain an explicit incomplete interval rather than claiming that reconnecting restored every event.