Context
From adversarial review of v0.4.0b1 (W12).
Problem
The ChangeStream sequence counter starts at 0 every time the server starts. If a client reconnects after a restart with cursor=500 from the previous run, replay_from(500) returns [] because the buffer is empty and new sequences start at 1. The client receives events from seq 1 onward with no indication these are from a different server epoch.
This means:
- Clients may believe they're caught up when they've actually missed all events from the previous epoch
- Sequence numbers from different epochs can collide, breaking deduplication logic
Suggested approaches
- Persist sequence counter: Store the last-assigned seq in the database and restore on startup
- Epoch ID: Include a server generation/epoch identifier in each event so clients can detect restarts
- Timestamp-seeded counter: Initialize seq from a high-resolution timestamp to avoid collisions (simpler but less robust)
Acceptance criteria
- Clients can detect server restarts
- Sequence numbers do not collide across restarts
- Replay deduplication remains correct across restarts
Context
From adversarial review of v0.4.0b1 (W12).
Problem
The
ChangeStreamsequence counter starts at 0 every time the server starts. If a client reconnects after a restart withcursor=500from the previous run,replay_from(500)returns[]because the buffer is empty and new sequences start at 1. The client receives events from seq 1 onward with no indication these are from a different server epoch.This means:
Suggested approaches
Acceptance criteria