Files
Bose-SoundTouch/pkg
Tobias GesellchenandClaude Opus 5 6c40d9a6cc fix(player): reconnect in place instead of reloading the page
The player reloaded itself five seconds after its status socket closed. That
cannot work while the service is down, because the document is served by that
same service: the tab left a working UI for the browser's error page, lost
whatever it held (a pending source command, the selected device, scroll
position) and stayed there until reloaded by hand.

The socket now reconnects with exponential backoff, from 1s to 15s, and a
banner says the connection was lost. The page stays usable and recovers on
its own when the service returns, with no interaction.

This is only safe because of the epoch added alongside the source-selection
work. A restarted service publishes revisions from 0 again, and revisions are
only comparable within one epoch; without it a reconnected socket would
deliver a sequence the browser rejects forever, leaving the page silently
frozen. Reloading was presumably how that was avoided before.

The regression test drives the outage through a TCP proxy it can take down
and bring back at the same address. Simulating this needs both refusing new
connections and severing established ones: a server that stops accepting
leaves an open WebSocket running, and Chrome's offline emulation does not
close it either, so neither reproduces a service that went away. Against the
old behaviour the test fails with "Inspected target navigated or closed",
which is the reload destroying the page.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-05 20:57:34 +02:00
..