fix(server): surface parse/validation transport errors via onerror in streamable HTTP

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.

[Maverick-666]

Summary

This PR fixes missing onerror propagation in StreamableHTTPServerTransport when request parsing/validation fails.

What changed

• Updated packages/server/src/server/streamableHttp.ts:
  • call this.onerror?.(...) when req.json() fails
  • call this.onerror?.(...) when JSONRPCMessageSchema.parse(...) fails
• Added regression tests in packages/server/test/server/streamableHttp.test.ts to verify both paths trigger onerror

Why

Previously, these transport-level errors could be handled in HTTP responses but were not reported through onerror, making observability and custom error handling inconsistent.

Validation

• pnpm --filter @modelcontextprotocol/server test -- test/server/streamableHttp.test.ts
• Targeted lint/format checks for modified files

Closes#1395

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02634bf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1684

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1684

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1684

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1684

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1684

commit: 02634bf

[Maverick-666]

Quick follow-up: all required project CI checks are passing, and this PR is ready for code-owner review.

One external review check (Claude Code Review) appears to be stuck in progress for over an hour. Could a maintainer please take a look when convenient?

[Maverick-666]

Maintainer follow-up: all required CI jobs for this change are green, but the external Claude Code Review check has been stuck in in progress for ~8 hours.

Could someone with write access please re-run/cancel that check (or mark it non-blocking for this PR) and proceed with code-owner review when convenient?

[travisbreaks]

Heads up: PR #1687 addresses the same root issue (#1395) with a broader approach. Instead of patching individual catch blocks, it moves the onerror call into createJsonErrorResponse() itself, which covers all ~15 call sites at once (not just the two parse failures patched here).

This PR has one advantage over #1687: it preserves the actual caught error object (error instanceof Error ? error : new Error(String(error))) rather than wrapping it in a new Error with the generic JSON-RPC message string. That fidelity matters for logging and observability.

If #1687 lands first, the two catch blocks you patched here would already have onerror coverage via the centralized path, making this PR a no-op. If this lands first, #1687 would need a rebase.

A couple of notes specific to this PR:

1. Missing changeset (the changeset bot flagged this).
2. The scope is intentionally narrow, covering only two of several silent error paths. Others (invalid Accept header, invalid Content-Type, session validation, protocol version checks) remain uncovered.

I'd suggest coordinating with the author of #1687 to pick one direction. The strongest outcome would be #1687's centralized architecture combined with your pattern of forwarding the real error object.

[Maverick-666]

Thanks for the detailed review — this makes sense.

I agree we should avoid parallel fixes for the same root issue. I’ll align with #1687’s centralized approach and avoid duplicating effort.

My main concern to preserve is forwarding the original caught error object for observability. I’ll follow up on #1687 with that improvement + tests.

[Maverick-666]

Closing this in favor of #1687 to keep one canonical implementation path.

I’ll contribute the remaining improvement there: preserving the original caught error object while using the centralized onerror path.