Reconnect with backoff

The status board moves through connecting, live, reconnecting, stale, and offline states instead of showing an eternal green dot. That contrast gives us something useful to test instead of a rule to memorize.

Immediate synchronized reconnects multiply an outage; backoff spreads attempts while the UI explains that data may be stale. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can retry every connection in a tight fixed loop and hide the state from the user and still get one successful demo. Push past the demo. cap a jittered exponential delay, reset it after stability, and render the age of the last confirmed update, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Make the final state correct through duplicates, gaps, restarts, multiple tabs, and temporary network loss. Save the before-and-after evidence now; it will make the final project review much more honest.

Simulate a five-minute outage with many clients and graph reconnect attempts per second. Save the evidence, then explain which requirement would force you to choose a different design.