fix: correct stdout buffering issues in spawned processes #739
+8
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds stdio inheritance to prevent Node.js from dropping console output after 8192 characters due to premature stdout pipe closure before output finishes flushing. Without this, calls like this would truncate after 8192 characters, leading to broken json output:
It would normally print as much would fit in the default buffer of the child_process (controlled by maxBuffer, which defaults to 8192 characters), and would fail to print the rest because the node child_process buffer was at it's limit. When the process is
spawn
instead ofexec
d, the data buffer passing is all that sends stuff back and forth, unless you set stdio to inherit in which caseconsole.out
in the child process would print directly to stdout instead of to a pipe. Since the output isn't needed, we don't need to keep it as a pipe.You can see this in their openapi spec, which powers their MCP server.
Validated with:
Prior to the change, running the second command would truncate the response