You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Client] Print contents of stderr when command in StdioTransport fails to start #332
Is your feature request related to a problem? Please describe.
Currently when command fails to start all I get is "Error Initialization failed: Request timed out", which is hard to debug.
Describe the solution you'd like
Print a more specific error message and the contents of stderr that was outputted when starting the MCP server
Describe alternatives you've considered
Add debugging code to library source or use xdebug
I reproduced it on current main with a child process that writes to stderr and exits with code 7. StdioTransport keeps polling until the initialization timeout and only reports Initialization failed: Request timed out.
The transport currently logs and discards stderr, and its polling loop never checks whether the child process has stopped.
I'd keep the change scoped to Client\Transport\StdioTransport: retain a bounded tail of stderr, check proc_get_status() while polling, and fail the pending operation immediately with the exit status and captured stderr. Tests would use a real PHP child process and cover fast non-zero exit, stderr in the error, truncation, and the successful-response-before-exit case.
Does that approach sound right? If so, I'm happy to send a PR.
Activity
perk11 commentedon May 26, 2026
Additionally, it would be great if it would fail right after the process exits and wouldn't wait for the timeout.
wWzZb commentedon Aug 14, 2026
Hi, I'd like to work on this.
I reproduced it on current main with a child process that writes to stderr and exits with code 7.
StdioTransportkeeps polling until the initialization timeout and only reportsInitialization failed: Request timed out.The transport currently logs and discards stderr, and its polling loop never checks whether the child process has stopped.
I'd keep the change scoped to
Client\Transport\StdioTransport: retain a bounded tail of stderr, checkproc_get_status()while polling, and fail the pending operation immediately with the exit status and captured stderr. Tests would use a real PHP child process and cover fast non-zero exit, stderr in the error, truncation, and the successful-response-before-exit case.Does that approach sound right? If so, I'm happy to send a PR.
[Client] Report the stdio server's exit code and stderr when it dies
[Client] Report the stdio server's exit code and stderr when it dies