openStream() only established the TCP/TLS connection; it never checked
the HTTP status code. A 4xx/5xx response (wrong stream path, station
temporarily down, etc.) still returned a valid client handle, so
streamWhileEnabled() entered its pump loop, immediately read 0 bytes
(no body), and returned -- skipping the kReconnectDelay branch
entirely, which only fired when openStream() itself returned nullptr.
run()'s outer loop then retried immediately: a full TCP+TLS handshake
in a tight loop bounded only by network RTT, not the intended 5s
backoff -- observed live at roughly 2 attempts/second.
This mattered beyond wasted reconnects: a concurrent full FM band scan
(POST /api/tuner/scan/full, which legitimately takes 70-135s) lost its
HTTP connection outright while this loop was running, before this fix.
After adding the status-code check and routing non-2xx through the
same reconnect delay as a failed connection, the same scan completed
cleanly twice in a row under the same conditions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
micheleandClaude Sonnet 5
36cd85f4d0