Handle MCP transport timeouts and disconnects

[anthonyivn2]

Summary

• configure the MCP HTTP client with timeout values matching the MCP Python SDK’s recommended client defaults: 30 seconds for connect/write/pool and 300 seconds for reads
• raise exceptions yielded by MCP transport streams instead of forwarding them as messages
• treat unexpected upstream EOF as a transport failure while preserving clean shutdown when the client closes stdin

Issues the PR resolves

Align the custom HTTP client with MCP SDK timeouts

Problem: ucode supplies its own HTTPX client to attach Databricks per-request authentication. This bypasses the SDK client factory and its timeout configuration, leaving HTTPX’s 5-second read-inactivity default in effect. A slow GitHub MCP response can therefore disconnect while the operation is still valid.

The MCP protocol does not mandate timeout values. The 30-second connect/write/pool timeout and 300-second read timeout come from the MCP Python SDK implementation in v2.1.1.

Fix: explicitly configure these values on ucode’s authenticated client so it retains the SDK-recommended timeout behavior.

Code: src/ucode/mcp_proxy.py — _run()

Propagate errors yielded by MCP streams

Problem: MCP read streams can yield an Exception instead of a protocol message. The proxy previously forwarded every yielded value to stdio, so it did not recognize this value as a transport failure.

Fix: detect and raise yielded exceptions. The bridge terminates with the original error, allowing the client to observe that the MCP connection failed.

Code: src/ucode/mcp_proxy.py — _pump()

Fail when the upstream stream closes unexpectedly

Problem: some transport failures surface to the proxy only as upstream EOF. Both proxy directions previously treated EOF as normal completion. The upstream pump could therefore finish successfully while the client-input pump continued waiting on stdin, leaving the proxy alive but unable to receive tool responses. Claude would continue showing the tool call as running.

Fix: treat completion of the upstream pump as an error. The error cancels the client-input pump and terminates the proxy. The client-input pump remains the normal control path, so Claude closing stdin still cancels the upstream task and shuts down cleanly.

Code: src/ucode/mcp_proxy.py — _pump_upstream() and _run()

Testing

• uv run --frozen pytest tests/test_mcp_proxy.py -q — 27 passed
• uv run --frozen ruff check .
• git diff --check

[sunishsheth2009]

Approved the PR, can we confirm that this PR will resolve this issue?