Streamable HTTP client logs a WARNING for valid 202 Accepted on session termination (DELETE)

[deadczarvc]

Problem

mcp/client/streamable_http.py treats any DELETE session-termination response outside {200, 204} as a failure and logs:

WARNING mcp.client.streamable_http: Session termination failed: 202

But 202 Accepted is a valid, spec-compliant response for an asynchronous delete — the server accepted the request and will process it later. The current code path:

if response.status_code == 405:
    logger.debug("Server does not allow session termination")
elif response.status_code not in (200, 204):
    logger.warning(f"Session termination failed: {response.status_code}")

Evidence

A long-running Hermes Agent (NousResearch) deployment with several Streamable HTTP MCP servers accumulated 72 Session termination failed: 202 warnings in ~36 hours in errors.log — pure noise from servers that correctly answer 202 to asynchronous termination. Real failures (connection errors) also surface through this same line, so the constant false positives bury the signal.

Suggested fix

Treat 2xx as success on termination, e.g.:

if response.status_code == 405:
    logger.debug("Server does not allow session termination")
elif 200 <= response.status_code < 300:
    pass  # 200/202/204 all acceptable
else:
    logger.warning(f"Session termination failed: {response.status_code}")

Environment

• mcp Python SDK (client, streamable HTTP transport), observed on recent Hermes 0.21.x installs
• Servers: multiple Streamable HTTP MCP endpoints (remote + local)

Happy to send a PR if the direction is agreed.

[0xamlab]

Confirmed on main (6affe5c): terminate_session in src/mcp/client/streamable_http.py warns for any DELETE status outside (200, 204). The spec only carves out 405 for this request; under HTTP semantics any 2xx is success, and 202 is the correct response for a server that processes the termination asynchronously — so the warning is a false positive.

Proposed fix, matching the direction suggested in the issue:

• Treat any 2xx as success: elif not 200 <= response.status_code < 300: — keeps the 405 debug path, and the warning still fires for genuine failures (4xx/5xx). If you'd rather keep it narrow ((200, 202, 204)), happy to go that way instead.
• Tests in tests/shared/test_streamable_http.py next to the existing termination tests: drive the DELETE through streamable_http_client with an in-process ASGI transport that rewrites the DELETE response status, parametrized over 200/202/204 asserting no Session termination failed warning is logged, plus a 500 case asserting the warning still fires (that case also covers the warning line currently behind # pragma: no cover).

Change targets main per the branching model; a v1.x backport would be your call.

Could a maintainer assign this to me? I'll open the PR once assigned, per CONTRIBUTING.

Disclosure: I'm contributing on behalf of thyn-ai, and used AI assistance while preparing this change. I've run the fix and tests locally and can speak to the change directly.

[pranavkrishnadanda]

Hi, I prepared a fix and test for this at pranavkrishnadanda/python-sdk@d46ad8b0 . The change treats all 2xx responses as
success on session termination and adds parametrized coverage for 200/202/204/405/500. Happy to open a PR if you’re not already working on it — otherwise I’ll step back.

[deadczarvc]

Update on approach, since two follow-up comments described the same direction.

Fix (terminate_session in src/mcp/client/streamable_http.py): replace the membership test with a range check -

if response.status_code == 405:
    logger.debug("Server does not allow session termination")
elif not 200 <= response.status_code < 300:
    logger.warning(f"Session termination failed: {response.status_code}")  # pragma: no cover

The 405 debug path and the warning for genuine failures (4xx/5xx) are unchanged. Range check over an explicit (200, 202, 204) tuple: RFC 9110 sec 9.3.3 makes any 2xx a success signal, and servers may return other 2xx codes, so the range covers the class instead of enumerating codes. The Streamable HTTP spec itself only carves out 405 for DELETE.

Test (added in tests/shared/test_streamable_http.py, reusing the existing AnswerDeleteWith204 wrapping-transport pattern): parametrized over 202 (assert no Session termination failed warning) and 500 (assert the warning still fires). Verified red on unmodified main for the 202 case, green after the one-line change. The existing test_streamable_http_client_session_termination_204 keeps covering 204.

Full diff with tests is on deadczarvc/python-sdk@fix/termination-2xx (commit 64907f9); the PR I opened from it was auto-closed by the require-linked-issue workflow, so it sits there as a reference diff. 75/75 tests in that file pass locally on 3.14/Windows; ruff and pyright clean.

[deadczarvc]

Confirming the repro from #3548 (now closed pending assignment) with additional CI-validated context:

Repro: terminate_session() in src/mcp/client/streamable_http.py treats only 200/204 as success and logs Session termination failed: 202 for any other status. We run several Streamable HTTP MCP servers from a long-lived agent deployment and accumulated 72 spurious Session termination failed: 202 warnings in ~36 hours in errors.log, which buries genuine 4xx/5xx failures surfacing through the same log line.

Why it matters: per HTTP semantics 202 Accepted is a success response; the Streamable HTTP spec only carves out 405 for the DELETE. A server that processes termination asynchronously (which 202 implies) is fully conformant — warning on it is a false positive.

Proposed approach: a one-line condition change (elif not 200 <= response.status_code < 300:), with the 405 debug path and genuine-failure warnings unchanged. A parametrized test (202 → no warning, 500 → warning still logged) covers both branches; it passed the repo's full matrix on the branch attached to #3548 except for two coverage-mechanics failures that I've since fixed on the branch (a stale # pragma: no cover on the now-covered warning line, and # pragma: no branch on the test's CM chain for Python 3.14 branch attribution).

Happy to rebase or adjust if maintainers prefer a different shape. Would appreciate consideration for assignment to this issue.