test: regression test for initialize hang on unexpected content-type

[Christian-Sidak]

Summary

• Adds a regression test (test_initialize_does_not_hang_on_unexpected_content_type) that directly reproduces the hang described in issue Initialize call hangs forever if MCP server does not return a Content-Type: text/plain #2432
• The test creates a minimal HTTP server that returns Content-Type: text/plain for all requests (including initialize) and asserts that session.initialize() raises MCPError immediately instead of blocking forever

The underlying fix is already present on main — _handle_post_request sends a proper JSONRPCError (with the matching request ID) when it encounters an unexpected content type, which lets ClientSession resolve the pending request instead of waiting indefinitely. This PR adds the missing test that exercises that code path for the initialize call specifically.

Test plan

• tests/client/test_notification_response.py::test_initialize_does_not_hang_on_unexpected_content_type — new test passes
• All existing test_notification_response.py tests continue to pass

Fixes#2432

[Christian-Sidak]

Friendly bump -- let me know if anything needs changing.

[Christian-Sidak]

Friendly bump -- let me know if anything needs changing.

[MukundaKatta]

Does the same fix path also cover a server returning 200 with an empty body, or 200 with valid JSON for a different request id? Both have the same "initialize never resolves" shape, so if the fix is at the right layer they should unblock without new code. If those cases are tested elsewhere already, ignore.

[Christian-Sidak]

No — this test is scoped to the unexpected content-type path only. The hang in issue #2432 is triggered when the SDK reaches the if content_type not in ("application/json", "text/event-stream") guard and raises McpError; the initialize() future is resolved by that error propagation.

The two cases you describe follow different paths:

• 200 with empty body: content-type would still be application/json (or absent), so it bypasses the content-type check. The body JSON-parse would fail or produce an empty response, which is a separate code path — likely a different hang or error class.
• 200 with valid JSON for a different request id: the response matcher would never complete the outstanding initialize future since the id doesn't match, so the session would hang differently — at the response-matching layer, not the content-type layer.

Both are valid "initialize never resolves" failure modes but would need separate tests against the relevant code paths. Happy to add them here or in a follow-up PR if that's useful.

[Christian-Sidak]

Friendly bump -- let me know if anything needs changing.

[Christian-Sidak]

Rebased onto current main: the streamable-HTTP test module has since moved from httpx/mcp.types to httpx2/mcp_types (repo-wide rename), so the new regression test needed the same update to avoid a NameError once merged. Content/behavior of the added test is unchanged.

[cubic-dev-ai]

2 issues found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="tests/client/test_notification_response.py">
<violation number="1" location="tests/client/test_notification_response.py:9">
P1: Test collection now fails because the project provides `httpx`, not `httpx2`. Keep the existing `httpx` import and corresponding `httpx.AsyncClient`/`httpx.ASGITransport` references so this regression test module can run.</violation>
<violation number="2" location="tests/client/test_notification_response.py:10">
P1: This changes SDK type imports to an uninstalled `mcp_types` module, so pytest cannot import this file. Import `types` from `mcp` and `RootsListChangedNotification` from `mcp.types` instead.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: This changes SDK type imports to an uninstalled mcp_types module, so pytest cannot import this file. Import types from mcp and RootsListChangedNotification from mcp.types instead.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tests/client/test_notification_response.py, line 10:
<comment>This changes SDK type imports to an uninstalled `mcp_types` module, so pytest cannot import this file. Import `types` from `mcp` and `RootsListChangedNotification` from `mcp.types` instead.</comment>
<file context>
@@ -6,17 +6,18 @@
-import httpx
+import httpx2
+import mcp_types as types
import pytest
+from mcp_types import RootsListChangedNotification
</file context>

[cubic-dev-ai]

P1: Test collection now fails because the project provides httpx, not httpx2. Keep the existing httpx import and corresponding httpx.AsyncClient/httpx.ASGITransport references so this regression test module can run.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tests/client/test_notification_response.py, line 9:
<comment>Test collection now fails because the project provides `httpx`, not `httpx2`. Keep the existing `httpx` import and corresponding `httpx.AsyncClient`/`httpx.ASGITransport` references so this regression test module can run.</comment>
<file context>
@@ -6,17 +6,18 @@
import json
-import httpx
+import httpx2
+import mcp_types as types
import pytest
</file context>

[Christian-Sidak]

Re cubic's review: the httpx2/mcp_types imports (flagged P1) are correct as-is — main already renamed these (see pyproject.toml's httpx2>=2.5.0 dependency and src/mcp-types/mcp_types), so this matches the current tree, not a regression.

Addressed the P2 point: wrapped the initialize() await in test_initialize_does_not_hang_on_unexpected_content_type with anyio.fail_after(5) so a reintroduced hang fails the test deterministically instead of stalling the run. Pushed as 5ef8194.

[Christian-Sidak]

Friendly bump -- let me know if anything needs changing.

[maxisbey]

Thanks for the PR. Equivalent coverage is already on main: test_unexpected_content_type_sends_jsonrpc_error landed with the #2005 fix, and the branch here has since conflicted with the httpx2/mcp_types renames. Closing this as part of a wider backlog cleanup following the v2 launch. If you think the initialize-triggered variant covers a genuinely distinct path, feel free to reopen and say so.

_{AI Disclaimer}