A /events stream that resumes from a cursor no longer copies the held window (#44). Before, replay_from cloned every event after the cursor into the stream's own Vec: up to 4,096 events, roughly 32 MiB per stream at the record cap, across as many as 512 streams. Now the window holds the same Arc<Announced> the broadcast carries, frozen into one shared slice on the first resume after a change. A stream holds that slice, an offset and the last position it covers, and drops it once the backlog is sent. The caps are unchanged.
Two ordering fixes go with it. A stream now subscribes to the broadcast while it holds the window lock, and skips live events its backlog already covered, so nothing between the replay and the live tail is lost or sent twice. And announce_from and relay now take the window before the sequencer, holding it across the position, the push and the send. Concurrent announcers used to be able to put positions into the window and onto the stream out of order. The window lock is the outer one, and no path takes the two the other way round.
tests/order.rs checks that eight resuming streams share one allocation of the window. tests/reseed.rs checks a resume over a real /events stream across the replay/live boundary. A third test runs eight announcers and four resuming streams at once over 304 events, and requires every stream to see every position once, in order. Without the lock-order change it fails, with 0:76, 0:70, 0:77 arriving out of order; with it, it has passed every run. All 468 index and query tests pass.
🤖 Generated with Claude Code