Background
DEVEX-669 (#1100) added BufferingLogger, which flushes buffered below-level connection logs into the "Coder" output channel on a genuine, surfaced connection failure:
- a reconnecting WebSocket terminal failure (
unrecoverable_close, unrecoverable_http, or certificate_error; a handshake 401 is excluded because a token refresh reconnects the same socket);
- a failure while opening a workspace (canceled build, missing agent, timeout, or CLI/certificate error).
During Ehab's review of #1100 we agreed to defer one additional trigger: flushing after N consecutive failed reconnect attempts against an unreachable server.
Problem
When a server is simply unreachable, the reconnecting WebSocket keeps retrying with backoff and never reaches a terminal failure reason, so the buffer is never flushed. A user reproducing a "can't connect / hangs on connecting" problem therefore gets no buffered detail in their support bundle, even though plenty of below-level context was captured.
Proposal
Flush the connection log buffer once a reconnect loop has failed N consecutive times (i.e., treat sustained unreachability as a genuine failure worth surfacing), then avoid re-flushing on every subsequent attempt until a successful connect resets the counter.
Open questions to settle during implementation:
- Value of N (or a time-based threshold instead of / in addition to a count).
- Where the counter lives and how it resets on a successful open.
- Guarding against repeated flushes while still stuck (flush once per failure "episode").
- A meaningful flush
reason/route for attribution, consistent with the existing terminal-failure reasons.
References
🤖 Filed by Coder Agents on behalf of @aqandrew, following up on the #1100 review.
Background
DEVEX-669 (#1100) added
BufferingLogger, which flushes buffered below-level connection logs into the "Coder" output channel on a genuine, surfaced connection failure:unrecoverable_close,unrecoverable_http, orcertificate_error; a handshake401is excluded because a token refresh reconnects the same socket);During Ehab's review of #1100 we agreed to defer one additional trigger: flushing after N consecutive failed reconnect attempts against an unreachable server.
Problem
When a server is simply unreachable, the reconnecting WebSocket keeps retrying with backoff and never reaches a terminal failure reason, so the buffer is never flushed. A user reproducing a "can't connect / hangs on connecting" problem therefore gets no buffered detail in their support bundle, even though plenty of below-level context was captured.
Proposal
Flush the connection log buffer once a reconnect loop has failed N consecutive times (i.e., treat sustained unreachability as a genuine failure worth surfacing), then avoid re-flushing on every subsequent attempt until a successful connect resets the counter.
Open questions to settle during implementation:
reason/route for attribution, consistent with the existing terminal-failure reasons.References
src/websocket/reconnectingWebSocket.ts,src/logging/logBuffer.ts🤖 Filed by Coder Agents on behalf of @aqandrew, following up on the #1100 review.