connectionTimeout defaults to 0, so nothing we own bounds a connect attempt

[cliffhall]

Follow-up from the investigation on #2188.

What

connectionTimeout defaults to 0:

// clients/web/src/utils/serverSettingsDefaults.ts:17
connectionTimeout: 0,

and InspectorClient.connect() reads it as "no bound at all":

const connectTimeoutMs = this.serverSettings?.connectionTimeout ?? 0;
// … the Promise.race and the transport teardown are both gated on `> 0`

So out of the box, nothing the Inspector owns bounds a connect attempt.

Why this is subtler than it looks

The reason this hasn't produced a flood of reports is that the SDK's own per-request timeout covers the initialize the handshake is waiting on. Measured against a server that accepts the TCP connection and never answers initialize:

0s:disconnected  →  2s:connecting  →  60s:error   ("Request timed out")

Exactly 60 seconds, every run. Which is the good news and the problem in one sentence: we are bounded by something we don't own, didn't ask for, and don't control the message of.

Three consequences worth weighing:

1. The coverage is incidental, not designed. It bounds what happens to sit inside an SDK request. Connect-time work outside one — transport.start(), and the OAuth work in OAuth path has no request timeouts outside token revocation #2319 when it isn't nested inside a request — has nothing bounding it.
2. The error belongs to the wrong layer. A user who waits out a failed connect is told Request timed out, which describes a JSON-RPC request, not a connection attempt. Connection timed out after N ms is the sentence that connect path already knows how to produce — it just never runs at the default.
3. 60s is a long time to look at a spinner with no indication that anything is wrong, and it is not a number anyone here chose.

The actual question

This is a product decision more than a bug, which is why it is filed as its own issue rather than folded into #2319: should connectionTimeout default to a real value?

Arguments for keeping 0: a slow server on a slow link is legitimate, and a default that fires early turns a working setup into a support question. Arguments for a real default: every other timeout in the product has one, "no bound" is not a sensible default for a network operation, and the current behavior only looks acceptable because a lower layer happens to cover the common case.

A reasonable middle: keep the effective bound generous, but make it ours and make it say so — so the failure reads as a connection timeout with the server's name in it, and the setting means what it says rather than being dead at its own default.

Honest scope

I found this while chasing #2188 and initially believed it was the cause. It is not — the measurement above is what ruled it out. Filing it because "the default disables the feature, and the only thing saving us is another layer's timeout" is worth a deliberate decision either way, not because anything is currently observed to be broken.

Decision

Let's add the timeout and make it 30 seconds. Update the message shown on timeout to include "To accommodate a slower server, you may increase the timeout value in Server Settings."

Related

• Server hangs forever at "Connecting..." when reconnecting with cached (still-valid) OAuth tokens #2188 — the investigation this came out of.
• OAuth path has no request timeouts outside token revocation #2319 — the OAuth path's missing timeouts; same theme, different layer.

[cliffhall]

Priority: Low (total 4)

• Severity 2 — minor friction with a workaround (the setting exists and a user can give it a value); the default merely disables it
• Urgency 2 — wanted eventually; nothing is blocked on it
• Bonuses: none claimed (see Add a per-server setting to suppress the standalone GET notification stream #2317 for why the milestone bonus is not taken on an issue filed through the create flow)

Typed question rather than enhancement deliberately: the deliverable is a decision about what the default should be, not an agreed change. If the answer is "give it a real default", that is a small follow-up; if it is "0 is correct, fix the error message instead", that lands in #2318.

Board: #28, Status Todo.

[cliffhall]

Shipped in #2362 (merged into v2/main as fb36797): connectionTimeout now defaults to 30 s when a server has no explicit value, an explicit 0 still means no timeout and is persisted, and the timeout message reads "Connection timed out after N ms. To accommodate a slower server, you may increase the timeout value in Server Settings."