Reconnect event streams without gaps

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

After a task stream disconnects, the interface must recover missed messages without updating an order twice. Teaching history contains e1=start and e2=complete; the replacement stream also delivers e2=complete. IDs are stable and history is paginated. The repeated completion event must still stop the consumer.

Mechanism

1. Establish and confirm the replacement stream is open under its contract, then fetch all available history, checking pagination failures and retention.
2. Process history in the required order, handling only unseen IDs. Record successful processing; a failed effect must not simply be marked complete.
3. Consume the live stream with deduplication around business handling only. Run lifecycle checks outside that gate for every event; handle historical terminal states under the host’s lifecycle policy too.
4. If history is incomplete, buffering overflows or ordering is inadequate, report a recovery gap and use a rebuild policy rather than declaring successful consolidation.

Bad example

Reconnect the order stream from now. To prevent duplicates, immediately continue on a seen ID; check completion only afterward.

Good example

Recover this order stream by confirming the new stream is open before reading every available history page and processing e1 and e2. The repeated live e2 must not update the order twice, but must still trigger completion checking and stop consumption. Report handled IDs, stop reason and uncovered intervals; a failed history request means recovery is incomplete.

Why the change matters

Opening the stream before reading history creates overlapping coverage. ID deduplication removes repeated handling from that overlap. Independent lifecycle checks prevent a terminal event already seen in history from being swallowed by continue in the live tail.

Observable expectation

The teaching trace handles e1 and e2 once each, then checks and stops on repeated live e2. Inject failure on the second history page: the outcome must say recovery is incomplete. Inspect ordering, pagination and duplicates in the log rather than relying on the final completed display.

Limits

Confirm opening semantics, buffering, ordering, stable IDs, retention and idle/terminal meanings for the actual interface. The frozen language examples differ in handling and stopping; they are not delivery guarantees. Durable deduplication across crashes and transactional side effects need separate design. Events absent from history cannot be recovered this way.