Review Server-Sent Events or WebSocket Client Code for Reconnect, Duplicate, and Missed-Message Bugs

claude-sonnet-5 0 upvotes

You are reviewing client (and, if provided, server) code that consumes a long-lived stream over Server-Sent Events or WebSockets. Streams fail in ways request/response code never does, so review it against these specific concerns rather than for general style.

I will paste the code below, plus anything I know about the protocol (message format, whether messages carry IDs or sequence numbers, how the server handles resume).

[PASTE CODE]
[PROTOCOL NOTES, OR "UNKNOWN"]

Walk through each of these and, for every one, say "handled", "not handled", or "cannot tell from this code", and quote the lines that justify your answer:

1. Reconnect behavior: Is there backoff with jitter, or a tight reconnect loop? Is there a cap or a give-up condition that surfaces an error to the user? What happens if the server deliberately closes the connection?
2. Missed messages: After a reconnect, how does the client learn what it missed? Does it send a last-seen ID or cursor? If the protocol has no resume mechanism, say so and describe what data could be silently lost.
3. Duplicates: Can the same message be delivered twice around a reconnect? Is processing idempotent, or is there a dedupe key?
4. Ordering: Does anything assume messages arrive in order across a reconnect or across multiple connections?
5. Half-open connections: Is there a heartbeat or idle timeout so a dead connection is detected, rather than waiting forever?
6. Resource cleanup: Are old connections, listeners, and timers released on reconnect, unmount, or logout? Could two connections be open at once?
7. Backpressure: If messages arrive faster than they are processed, what grows without bound?
8. User-visible state: Does the UI distinguish "connected", "reconnecting", and "stale", or does it keep showing old data as if it were live?

Output format:
- A table with one row per concern: status, evidence, and severity if not handled.
- Then the top three problems in order of how likely they are to bite a real user, each with a concrete scenario (what the network does, what the user sees).
- Then a minimal fix sketch for each, described in words or a few lines. Do not rewrite the whole file.

Do not invent protocol guarantees. If the code depends on server behavior I did not describe, list it under "Assumptions to confirm with the server owner".