Some transport errors are silently swallowed due to missing `onerror` callback usage

[joe-ohtani]

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