Context
From adversarial review of v0.4.0b1 (W10).
Problem
When a client provides a cursor that is older than the replay buffer window, replay_from() returns an empty list — the same result as "no new events, you're caught up." The WebSocket handler cannot distinguish between these two very different states.
A client that reconnects after a long outage silently misses events with no indication that data was lost.
Suggested approach
Return a richer result from replay_from() — either raise a CursorTooOld exception, or return a (events, is_complete: bool) tuple. The WebSocket handler can then send an #info error frame or close with an appropriate code when the cursor is outside the buffer window.
Acceptance criteria
- Client receives explicit notification when their cursor is too old
- Existing "caught up" behavior (empty replay, live streaming continues) is preserved
- Tests cover both cases
Context
From adversarial review of v0.4.0b1 (W10).
Problem
When a client provides a cursor that is older than the replay buffer window,
replay_from()returns an empty list — the same result as "no new events, you're caught up." The WebSocket handler cannot distinguish between these two very different states.A client that reconnects after a long outage silently misses events with no indication that data was lost.
Suggested approach
Return a richer result from
replay_from()— either raise aCursorTooOldexception, or return a(events, is_complete: bool)tuple. The WebSocket handler can then send an#infoerror frame or close with an appropriate code when the cursor is outside the buffer window.Acceptance criteria