Skip to content

feat(client): carry the originating HTTP status in ErrorData.data#3094

Draft
himanshu-commits wants to merge 2 commits into
modelcontextprotocol:mainfrom
himanshu-commits:feat/http-status-in-error-data-3091
Draft

feat(client): carry the originating HTTP status in ErrorData.data#3094
himanshu-commits wants to merge 2 commits into
modelcontextprotocol:mainfrom
himanshu-commits:feat/http-status-in-error-data-3091

Conversation

@himanshu-commits

Copy link
Copy Markdown

A non-2xx POST is synthesized into a JSON-RPC error whose code cannot express the retry decision: a terminal 401 and a transient 503 both arrive as INTERNAL_ERROR with the same "Server returned an error response" message. A caller cannot tell "my token is bad, stop" from "the server hiccuped, retry".

The status now rides along on error.data as {"httpStatus": 503}. data is free-form per the JSON-RPC spec, so this is additive: nothing that reads code or message changes.

An error the server supplied in its body keeps its own data untouched — its account of the failure outranks ours. A non-2xx to a notification has no waiter to resolve, so it is logged rather than dropped silently.

Requested on #3091 by the reporter, who needs the distinction for retry classification in a downstream client.

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

A non-2xx POST is synthesized into a JSON-RPC error whose code cannot express
the retry decision: a terminal 401 and a transient 503 both arrive as
INTERNAL_ERROR with the same "Server returned an error response" message. A
caller cannot tell "my token is bad, stop" from "the server hiccuped, retry".

The status now rides along on `error.data` as `{"httpStatus": 503}`. `data` is
free-form per the JSON-RPC spec, so this is additive: nothing that reads `code`
or `message` changes.

An error the server supplied in its body keeps its own `data` untouched — its
account of the failure outranks ours. A non-2xx to a notification has no waiter
to resolve, so it is logged rather than dropped silently.

Requested on modelcontextprotocol#3091 by the reporter, who needs the distinction for retry
classification in a downstream client.
`tests/test_examples.py` pipes every code block in `docs/troubleshooting.md`
through ruff, and on Windows that pipe is cp1252, not UTF-8: a `…` in the
snippet reached ruff as invalid UTF-8 and failed every Windows job. The
character carried no meaning the prose didn't already.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant