Control-poll failure ends a call immediately, even if the peer would recover

[charan-rathore]

useVoice polls GET /voice/calls/:id every 2 seconds. In src/client/useVoice.ts the .catch() on that poll sets Call control connection was lost. and calls end() right away. So one failed poll, for example during a short network flap, ends the call even if the peer connection would have recovered.

#26 adds a five-second grace period for RTCPeerConnection disconnected. It does not cover this path. Credit to kvnloo for spotting it in the review of #26.

I have not reproduced this in a real browser. This is from reading the code.

Questions to settle:

• Should a single failed poll end the call, or only a run of failures?
• Should the poll failure and the peer state share one "recoverable" window?

Acceptance cases suggested on #26:

• transient control-poll failure with a recoverable peer: observe whether the call still ends
• persistent peer or control failure: the call ends once, with one saved receipt

Written with AI help, checked against the source by me.

[jibraaan]

On the open question ("should the poll failure and the peer state share one recoverable window?"): I tried the shared-window approach in my fork, in case it helps decide between #26 and #39.

src/client/voice-recovery.ts is a small timer with no dependencies:

• The first fault from either source (a disconnected peer, or a failed control poll) opens a single 5-second window. The window closes only when both sources have recovered.
• If any fault remains when the window expires, the call ends once, with the first fault's message. failed still ends the call immediately.
• It is disposed on end() and closeMedia(), so a late timer can't end a newer call.

That covers both acceptance cases from #26: a transient poll failure with a recoverable peer keeps the call, and a persistent failure ends it once with one saved receipt. It also avoids the case where two independent timers both fire.

It's unit-tested with fake timers (tests/voice-recovery.test.ts), and the useVoice wiring is about 20 lines. Like #26 and #39, it hasn't been reproduced in a real browser call. I'm happy for either PR to adopt it rather than opening a third one.

Written with AI help, checked against the source.