A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. One failure is normal; a loop is repeated start-to-fail without a stable window. Detect it in the shared state machine, not individual UI components.
Observability should locate the failing stage, affected sessions, and whether impact is growing. Events use allowlisted low-cardinality dimensions; payloads, secrets, and complete network identity stay out.
Questions the design must answer
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Count attempts, repeated errorClass, and longest stable time over five minutes; open a local circuit above threshold, respect close, and offer one manual retry.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Use explicit capability negotiation so older clients receive an explained fallback instead of a half-working state.
The delivery standard for Detecting Reconnect Loops Before Users See Endless Connecting is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Failure count alone misclassifies deliberate multi-device testing, while hiding the banner without persisting stop intent leaves the loop running.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- User or task IDs in metric labels create high-cardinality cost and leak unnecessary identity into diagnostics.
Prove that it works with evidence
A release gate combines deterministic regression, randomized timing, and real browser pairs. Preserve the seed and state trace from every failure as a permanent replay case.
- Replay fast failures, brief success, user close, network recovery, and multiple peers; only the looping target should trip within privacy limits.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.