Repository navigation
fix(server): flush stdout and ensure line-buffering before restoring fd 1 (#3821) - #3835
nikolas-sapa wants to merge 1 commit into
Conversation
|
This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3821. If a maintainer assigns you to #3821, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take. You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way. CONTRIBUTING.md has the full reasoning, but in short:
Maintainers: reopen, remove |
PR Draft: Flush stdout and ensure line-buffering before restoring fd 1
PR Title:
fix(server): flush stdout and ensure line-buffering before restoring fd 1 (#3821)Branch:
fix/stdio-flush-line-bufferingSummary
Resolves #3821: In
stdio_server, unbuffered writes or missing flush before restoring stdout/fd 1 causes JSON-RPC messages to interleave or hang on client pipes.Root Cause
When
stdio_serverstarts, fd 1 is diverted to stderr (or/dev/null) while the original wire descriptor is maintained privately for JSON-RPC framing. However, when standard streams are connected to pipes, Python's default buffering mode forsys.stdoutis block-buffered (line_buffering=False). Stray writes made tosys.stdout(e.g. from sub-libraries or third-party loggers writing without explicit flushes) remain buffered in Python's user-space buffer while fd 1 points to the diversion.During teardown,
_restore_fd(1, ...)restores fd 1 back to the wire. Ifsys.stdoutis not flushed prior to restoring the descriptor, those buffered stray bytes are flushed after fd 1 is restored, dumping arbitrary non-JSON-RPC text directly onto the client transport pipe. This leads to client framing parse errors, corrupted streams, and deadlocks. Additionally, restoringsys.stdoutwithout line-buffering leaves subsequent writes prone to blocking or delayed delivery.Changes
_restore_fd(fd, private_fd): Whenfd == 1, flushsys.stdoutand callsys.stdout.reconfigure(line_buffering=True)beforeos.dup2(private_fd, fd)._claim_fd(fd, stream, ...)release(): Explicitly flush bothsys.stdoutandstream, and reconfigure line buffering before restoration._claim_fd(...): Flushsys.stdoutandstreambefore redirecting fd 1 to the diversion to ensure pre-existing buffer contents do not spill across fd states.stdio_server(...): Wrapstdout_bufferwith_UnownedTextWrapper(..., line_buffering=True).tests/conftest.py: Allowos.write,io.BufferedWriter.write,io.TextIOWrapper.writeinmcp/server/stdio.pyduringreleaseand_restore_fd.test_stdio_server_flushes_stdout_and_ensures_line_buffering_before_restoreintests/server/test_stdio.py, testing unflushed writes duringstdio_serverlifespan are flushed to the diversion, line buffering is ensured on restore, and the client pipe receives zero leaked bytes.Test Verification
Ran full test suite in
tests/server/test_stdio.py:uv run --directory ~/scratch/agent_contributions/mcp_python_sdk/python-sdk pytest tests/server/test_stdio.pyOutput:
Linter verification: