Follow-up from the investigation on #2187.
Why
When a request times out, the Inspector says Request timed out and nothing else. For a debugging tool that is the least useful thing it could say: it names the symptom the user already sees and none of the state that would explain it.
#2187 is the worked example. The server was connected, initialize had succeeded, curl answered the identical tools/list in under 100ms, and the actual cause was a long-lived GET /mcp notification stream starving every subsequent POST on a concurrency-limited server. Every fact needed to suspect that was already in the Inspector's own process at the moment it gave up:
- the notification stream was open, and had been for the whole session without emitting a single event;
tools/list had been outstanding for 60s;- nothing else had been answered since
notifications/initialized.
The reporter got none of it, and reasonably concluded the fault was in the Inspector's session handling. #2188 is plausibly the same shape wearing a different hat, and was filed separately for the same reason.
What
Surface the connection's outstanding state at the point of a timeout, rather than making the user reconstruct it from the Network tab. Roughly:
Request timed out after 60s. The notification stream (GET /mcp) has been open for 4m12s and has emitted no events; 1 request is outstanding and no response has been received since notifications/initialized.
The specific signals worth having:
- whether the standalone GET stream is open, how long it has been open, and how many events it has delivered — a stream that has delivered zero events for the whole session is the tell;
- the count and age of outstanding requests;
- when the last response of any kind arrived.
Notes
- This is presentation over state we already hold: the fetch tracker sees the GET stream's lifetime (it already classifies it via
isLongLivedStreamResponse to avoid reading its body), and the message log knows what is outstanding and when the last response landed.
- The timeout message is the highest-value placement, but the same summary would earn its keep on the Connection Info panel while a request is in flight.
- Keep it factual. It should report what the connection's state is and let the reader draw the conclusion — not assert a diagnosis the Inspector cannot actually verify from its own side.
Related
Follow-up from the investigation on #2187.
Why
When a request times out, the Inspector says
Request timed outand nothing else. For a debugging tool that is the least useful thing it could say: it names the symptom the user already sees and none of the state that would explain it.#2187 is the worked example. The server was connected,
initializehad succeeded,curlanswered the identicaltools/listin under 100ms, and the actual cause was a long-livedGET /mcpnotification stream starving every subsequent POST on a concurrency-limited server. Every fact needed to suspect that was already in the Inspector's own process at the moment it gave up:tools/listhad been outstanding for 60s;notifications/initialized.The reporter got none of it, and reasonably concluded the fault was in the Inspector's session handling. #2188 is plausibly the same shape wearing a different hat, and was filed separately for the same reason.
What
Surface the connection's outstanding state at the point of a timeout, rather than making the user reconstruct it from the Network tab. Roughly:
The specific signals worth having:
Notes
isLongLivedStreamResponseto avoid reading its body), and the message log knows what is outstanding and when the last response landed.Related