Repository navigation
Some transport errors are silently swallowed due to missing onerror callback usage #1395
Description
Describe the bug
Several transport.handleRequest error types are silently swallowed by the SDK even when using the onerror callback set on the transport. This prevents any form of debugging, logging, or observability of those errors.
For example, if a Parse error: Invalid JSON-RPC message happens within handlePostRequest (which is used by handleRequest), it's impossible currently to know what that error was, or even to know that it occurred.
See this example error in the source code. This has its own nested try/catch block that calls createJsonErrorResponse, but does not call this.onerror.
At the end of the parent function, within the catch, you can see this.onerror?.(error as Error); is called before createJsonErrorResponse. This is fine - the onerror callback is fired, so we can get access to any errors that make it this far. But if the error occurs within any of the nested try/catch blocks, this final catch is never reached, and the callback is never fired.
I understand that you could make the distinction between 'expected'/handled errors, which you might argue are 4xx-style warnings rather than full-blown errors, and 'exceptions/unhandled' errors, which constitute the equivalent of a 5xx status. But right now, my team is unable to debug why AWS AgentCore Gateway cannot connect to our MCP server, because AWS does not expose any response information for debugging, and neither does the SDK on our server.
To Reproduce
Steps to reproduce the behavior:
const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: () => uuid(),
});
transport.onerror = (error) => {
console.error(error); // this is never fired for certain error types
};Expected behavior
Expected behaviour is that any time an error response is sent, it should be observable/loggable.
Logs
N/A
Additional context
N/A
Activity
codewithkenzo commentedon Feb 2, 2026
I've submitted a fix for this in PR #1433.
The PR adds
this.onerror?.()calls to all the nested try/catch blocks that were silently swallowing errors. Now parse errors, session validation failures, and other handled errors will be observable through the callback.Let me know if you get a chance to test it against your AWS AgentCore Gateway setup!
fix: call onerror for silently swallowed transport errors
fix: call onerror for silently swallowed transport errors
fix: call onerror for silently swallowed transport errors
fix: call onerror for silently swallowed transport errors
fix: call onerror for silently swallowed transport errors
fix: call onerror for silently swallowed transport errors
fix: call onerror callback for all transport error responses
Maverick-666 commentedon Mar 16, 2026
I’m taking this one.
I can reproduce the current behavior where transport-level parse/validation errors are not surfaced via
onerrorinStreamableHTTPServerTransport.I’m preparing a focused fix + regression tests and will open a PR shortly.