Forward server stderr when errlog has no file descriptor

[maisymylod]

Closes #156.

Problem

stdio_client passes errlog straight to anyio.open_process(stderr=...), which needs a real OS file descriptor for the child to inherit. Writers that have none never work:

• Jupyter / ipykernel replaces sys.stderr with a stream whose fileno() raises io.UnsupportedOperation, so the server's stderr is lost. This is the case reported in support logging to stderr in Jupyter Notebook Environments. #156.
• io.StringIO, the obvious way to capture server logs in a test, fails the same way.

The spawn either raises io.UnsupportedOperation or sends diagnostics somewhere the caller never sees.

Fix

Check whether errlog has a usable descriptor. If it does, nothing changes: it is inherited exactly as before. If it does not, spawn with subprocess.PIPE and forward the pipe into errlog from a reader task.

Two details worth review:

• Shutdown drains the forwarder. Once the server is dead its stderr pipe is at EOF with at most a buffer left, so shutdown() waits (bounded, 0.5s) on the reader before the task group cancel takes it out. Without this the last diagnostics, which are exactly the ones you want when a server dies, race the cancel.
• ipykernel with fd capture stays on the inherit path. It does expose a descriptor once capture_fd_output is on, and that path already routes back to the notebook, so inheriting it remains correct.

A closed errlog (a finished notebook cell) is logged at debug and stops forwarding rather than failing the session.

FallbackProcess gained a stderr attribute so the Windows SelectorEventLoop path works too.

Tests

• test_server_stderr_output_reaches_an_errlog_without_a_file_descriptor reproduces support logging to stderr in Jupyter Notebook Environments. #156 with a real subprocess. It fails on main with the reported io.UnsupportedOperation.
• Two in-process tests cover the closed-sink and dead-pipe paths.
• The existing test_server_stderr_output_reaches_the_errlog_file still passes unchanged, pinning the inherit path.

Full suite passes and src/mcp/client/stdio.py stays at 100% coverage. (tests/server/test_streamable_http_modern.py::test_moderation... fails on a clean checkout too and is unrelated.)

AI disclosure

AI tooling was used to write and push the changes. The diagnosis, the approach, and the findings are my own, and I can speak to any of it.

[cubic-dev-ai]

1 issue found across 4 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/mcp/client/stdio.py">

<violation number="1" location="src/mcp/client/stdio.py:233">
P2: Final server stderr bytes can still be dropped during shutdown on asyncio. The new drain wait happens after `_stop_server_process()` closes the subprocess transport, so delaying transport close until after `stderr_done.wait()` in forward-stderr mode would make this drain reliable.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Final server stderr bytes can still be dropped during shutdown on asyncio. The new drain wait happens after _stop_server_process() closes the subprocess transport, so delaying transport close until after stderr_done.wait() in forward-stderr mode would make this drain reliable.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/client/stdio.py, line 233:

<comment>Final server stderr bytes can still be dropped during shutdown on asyncio. The new drain wait happens after `_stop_server_process()` closes the subprocess transport, so delaying transport close until after `stderr_done.wait()` in forward-stderr mode would make this drain reliable.</comment>

<file context>
@@ -193,13 +227,20 @@ async def shutdown() -> None:
+        # The server is dead, so its stderr pipe is at EOF with at most a buffer left;
+        # let the forwarder finish it before the task group's cancel takes the task out.
+        if forward_stderr:
+            with anyio.move_on_after(_STDERR_DRAIN_TIMEOUT):
+                await stderr_done.wait()
         await _aclose_all(read_stream, write_stream, read_stream_writer, write_stream_reader)
</file context>

[github-actions]

Thanks for the contribution. This repository only keeps pull requests open when they're linked to an issue that a maintainer has assigned to the author — CONTRIBUTING.md explains why and how we work. This PR has been closed for now because you aren't currently assigned to #156.

If a maintainer would like this change as a PR from you, they'll assign you to #156 and this PR will reopen automatically — there's nothing more you need to do. (If you opened the issue, this PR already shows up on its timeline.)

There's no need to open a new PR — this one will be reopened. While it's closed, please push any updates as new commits rather than force-pushing, since GitHub can't reopen a PR whose branch has been rewritten.

Maintainers: reopening this PR, removing the missing-issue-link label, or adding bypass-issue-check bypasses the check.