Problem
The current exponential backoff (1s → 2s → 4s → 8s → 16s → 30s cap) treats a planned gateway restart (SIGUSR1, ~5-10s downtime) the same as a hard outage. After 3-4 missed connect attempts during a normal restart, the next attempt waits the 30s cap — even though the gateway has been ready for 20+s.
Observed in Pinchy staging cold-start cascade (heypinchy/pinchy#189, #190):
14:48:45 Disconnected
14:48:46 attempt → fail (1s)
14:48:48 attempt → fail (2s)
14:48:52 attempt → fail (4s)
14:49:00 attempt → fail (8s)
14:49:16 attempt → fail (16s) ← gateway already ready at 14:49:37
14:49:54 attempt → succeed (30s wait)
That's ~50s of unnecessary wait after the gateway is ready.
Fix Options
a) Shorter cap (5-10s) for the common-case planned-restart pattern. Trade-off: more reconnect noise during real outages.
b) Reset backoff on quick disconnect — if the connection was `open` for <X seconds, treat the next reconnect as fresh (don't continue the multiplier). Same intuition as TCP exponential backoff resets.
c) Jittered reset — keep the cap but reset to base on every fresh connect attempt cycle.
(b) is probably best: it specifically targets the cold-start case without slowing real-outage recovery.
Acceptance
- After a 5-10s gateway restart, reconnect happens within ~3s of gateway being ready.
- Real outages (>60s) still apply meaningful backoff.
- Test exists that exercises the quick-disconnect path.
Diagnosed in Pinchy staging deploy 2026-04-29.
Problem
The current exponential backoff (1s → 2s → 4s → 8s → 16s → 30s cap) treats a planned gateway restart (SIGUSR1, ~5-10s downtime) the same as a hard outage. After 3-4 missed connect attempts during a normal restart, the next attempt waits the 30s cap — even though the gateway has been ready for 20+s.
Observed in Pinchy staging cold-start cascade (heypinchy/pinchy#189, #190):
That's ~50s of unnecessary wait after the gateway is ready.
Fix Options
a) Shorter cap (5-10s) for the common-case planned-restart pattern. Trade-off: more reconnect noise during real outages.
b) Reset backoff on quick disconnect — if the connection was `open` for <X seconds, treat the next reconnect as fresh (don't continue the multiplier). Same intuition as TCP exponential backoff resets.
c) Jittered reset — keep the cap but reset to base on every fresh connect attempt cycle.
(b) is probably best: it specifically targets the cold-start case without slowing real-outage recovery.
Acceptance
Diagnosed in Pinchy staging deploy 2026-04-29.