Bug: MCP transport (api.inference.sh) repeatedly times out and breaks — liveness probe failures throughout session

[Al629176]

Description

The MCP transport connection to api.inference.sh fails its liveness probe repeatedly throughout a session, triggering reconnects. Occurs every 15–60 minutes consistently.

Log evidence

```
09:17:22 WRN the liveness probe did not answer in time; keeping the session qualified_name=ac.inference.sh/mcp outcome="timed_out" probe_timeout_seconds=8 consecutive_timeouts=1
09:49:23 WRN the transport failed its liveness probe; reconnecting: mcp transport failure for https://api.inference.sh elapsed=1.961s
10:00:36 WRN liveness probe timed_out consecutive_timeouts=1
10:22:41 WRN liveness probe timed_out
11:11:48 WRN transport failed liveness probe; reconnecting elapsed=319ms
11:25:28 WRN liveness probe timed_out
13:39:39 WRN transport failed; reconnecting elapsed=1.670s
14:05:25 WRN liveness probe timed_out
14:26:38 WRN liveness probe timed_out
15:14:13 WRN liveness probe timed_out
15:34:46 WRN transport failed; reconnecting elapsed=707ms
16:21:21 WRN transport failed; reconnecting elapsed=3.503s
16:37:33 WRN liveness probe timed_out
17:40:53 WRN liveness probe timed_out
```

14+ failure events in a single session day.

Impact

• MCP tools unavailable during reconnect windows
• Agent silently loses tool access mid-task
• No user-visible indication when MCP transport is down

Acceptance criteria

• MCP liveness probe failures surface in Event Log
• User notified when MCP tools become temporarily unavailable
• Reconnect succeeds reliably and restores tool access
• Investigate why api.inference.sh probe times out so frequently (server-side or client probe interval too aggressive)

[tinysweeper]

MCP transport to api.inference.sh repeatedly times out on liveness probes, causing frequent reconnects and loss of tool access.

Labelled priority: p2.

[YellowSnnowmann]

Investigation notes and the fix, for the record.

What the log lines say, read against the code that emits them. These warnings come from tinymcp v0.3.2 (what main pins via #5772), which already carries tinymcp#5: a single probe timeout keeps the session, and it takes three in a row to tear one down.

• Every timed_out line above is at consecutive_timeouts=1. None of them dropped anything — they are tools/list round trips that took longer than the 8 s probe window, and the session was kept each time.
• The actual reconnects are the Broken lines: tools/list failed at the reqwest transport level in 0.3–3.5 s (mcp transport failure for https://api.inference.sh: …). The text after the colon is the part that says what happened (reset / EOF / TLS / decode), and it is cut off in the report. If you still have the raw log, that string is the one thing that would pin the cause.

Measured from here (2026-09-02, ~50 minutes). api.inference.sh/mcp is Cloudflare-fronted, answers unauthenticated initialize in 0.3–1.2 s and tools/list (25 tools) in 0.18–0.28 s:

run	probes	spacing	p50	max	failures	> 8 s
same keep-alive connection reused	25	60 s	0.19 s	0.90 s	0	0
fresh TCP+TLS dial + new session per probe	24	60 s	0.26 s	0.28 s	0	0

An idle keep-alive connection also stayed open for ≥ 150 s without the server closing it. So neither "probe interval too aggressive" nor "server slow" reproduces from this network; the timeouts and fast transport failures in the report look specific to the reporting machine's network path at the time (VPN / Wi-Fi / an upstream blip). The probe window (8 s) and interval (60 s) are left as they are — tinymcp#5's reasoning stands and nothing measured contradicts it.

Tool access after a reconnect was already restored by construction: the tool registry rebuilds from the live connection map on every call, and a tool call that lands inside the reconnect window returns NotConnected to the agent rather than nothing. What was missing was any signal to the user, which is what the fix adds.

Fix (two PRs):

• feat(supervisor): hand back what a tick observed as a TickReport tinymcp#13 — Supervisor::tick returns a TickReport of what it observed (probe answered / timed out / transport dropped / reconnected / reconnect failed / parked), so a host can route it. The supervisor still publishes nothing itself.
• feat(mcp): surface reconnect-supervisor outcomes in the Event Log and notifications (#5931) #5955 — bumps vendor/tinymcp onto that and (1) publishes each observation as an mcp_client domain event, so it shows in Settings → Developer → Event Log with the server name in the agent column, and the transport error text rides along on McpServerTransportDropped.detail; (2) notifies the user when a server stays down after a tick ("MCP server unavailable", with the retry delay and the error), when it comes back after failing, and when it is parked because its launcher runtime is missing — same-tick rebuilds and single slow probes stay Event Log only, so the fourteen-a-day pattern above would produce Event Log rows and zero banners; (3) makes the host's supervisor loop delay missed ticks instead of bursting them.

Acceptance criteria mapping: Event Log ✅ (1), user notified ✅ (2), reconnect restores tool access ✅ (already true; verified by reading, see the PR), investigation ✅ (above — not reproducible from here; the truncated error text is the missing piece).