fix(mcp): avoid probing JSON-RPC stdin for explicit batch input - #293
fix(mcp): avoid probing JSON-RPC stdin for explicit batch input#293EricLingRui wants to merge 1 commit into
Conversation
fc7d0d8 to
4a0ecf3
Compare
4a0ecf3 to
be64bbf
Compare
|
Closing — the bug this targets is already fixed on Your diagnosis was right, and it matched what we landed in The fix on I did look at what your branch adds on top of that, and it is real but no longer a correctness matter: gating the probe on Thanks for the careful write-up — the "explicit batch input should never touch the JSON-RPC channel" framing was exactly the right way to state the invariant. |
Summary
batchalready has an explicit non-stdin input and the warning is disabledbatch --commands/batch --inputcalls never read from the JSON-RPC transport--input -, and the existing ignored-stdin warning for normal CLI useRoot cause
The MCP server sets
OFFICECLI_BATCH_ALLOW_STDIN_REDIRECT=1because its stdin is the JSON-RPC transport. However, the old batch handler checked that flag only when deciding whether to print a warning, after it had already started a backgroundStdIn.Peek().When the 50 ms wait expired, the blocked task was abandoned but remained alive. Once the client sent its next JSON-RPC request, that task could buffer the request from stdin, leaving the MCP read loop without the expected message. The caller then waited until its tool timeout.
The fix decides whether the ignored-stdin warning is needed before starting the probe. MCP disables that warning, so it no longer creates a competing stdin reader. The mutual-exclusion check also runs before any possible probe.
Validation
Both the baseline (
459b1a47) and patched source were published forlinux-arm64with:I then ran the same MCP sequence against each binary: initialize, send a malformed string-form batch (which returns an error), then immediately send a valid argv-form batch.
Portable reproducer (set
OFFICECLIto the binary under test):The patched output is: