Skip to content

Conversation

lorenss-m
Copy link

Fix: Propagate HTTP errors to client

Motivation and Context

HTTP request failures were not being properly communicated to clients, causing silent failures. This fix ensures errors are sent through the read stream so clients are notified when requests fail.

How Has This Been Tested?

Has been tested in production environments (used by https://github.com/hud-evals/hud-python with a remote server).

Breaking Changes

None - this is a backwards-compatible error handling improvement.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)

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
  • Documentation not needed for this internal fix

Additional context

This change wraps the handle_request_async function in a try-catch block and sends any exceptions to ctx.read_stream_writer to ensure proper error propagation in the streamable HTTP transport layer.

Example scenario where this fix is critical:

HTTP Error Codes (502, 503, 504, etc.)

# Without this fix: Client hangs when server returns 502 Bad Gateway
# With this fix: Client receives the HTTP error
from mcp.client.streamable_http import streamablehttp_client
from mcp.client.session import ClientSession

async with streamablehttp_client(server_url) as (read_stream, write_stream):
    async with ClientSession(read_stream, write_stream) as session:
        await session.initialize()
        try:
            result = await session.call_tool("api_operation", arguments={})
        except Exception as e:
            print(f"Error received: {e}")  # Now properly catches 502, 503, 504 errors

@lorenss-m lorenss-m requested review from a team and Kludex August 26, 2025 08:30
@lorenss-m lorenss-m changed the title Catch http errors fix: Catch http errors Aug 27, 2025
@lorenss-m
Copy link
Author

@Kludex bumping this -- really important for our remote server to include this, our library is forced to depend on our fork otherwise!

Copy link
Contributor

@felixweinberger felixweinberger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @lorenss-m thanks for this contribution!

There seem to be a few competing approaches to handle this issue: #1194, #1008

We probably want to resolve them once in the right place, I will aim to take a look this week.

await self._handle_resumption_request(ctx)
else:
await self._handle_post_request(ctx)
except Exception as e:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is too broad of an error, we should be more specific about the type of Exception we handle here.

We should at least limit to HTTPStatusError if your problem is with HTTP errors specifically.

@felixweinberger felixweinberger self-assigned this Sep 23, 2025
@felixweinberger felixweinberger added needs more work Not ready to be merged yet, needs additional changes. needs maintainer action Potentially serious issue - needs proactive fix and maintainer attention labels Sep 23, 2025
@felixweinberger felixweinberger removed the needs more work Not ready to be merged yet, needs additional changes. label Sep 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs maintainer action Potentially serious issue - needs proactive fix and maintainer attention

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants