fix(streamable-http): reduce stateless termination log noise

[BlocksecPHD]

Summary

This PR adjusts termination logging in StreamableHTTPServerTransport for stateless mode.

• Keep INFO log for stateful session termination (session id exists)
• Emit DEBUG log for stateless transport cleanup (mcp_session_id is None)
• Update wording to reflect normal request completion in stateless mode

This addresses confusion reported in #2329 where users interpret Terminating session: None as an error condition.

Changes

• src/mcp/server/streamable_http.py
  • Conditional log level/message in terminate()
• tests/server/test_streamable_http_manager.py
  • Add regression test to assert:
    • debug message exists for stateless cleanup
    • info-style Terminating session: None message is not emitted

Validation

Ran targeted tests locally:

python -m pytest tests/server/test_streamable_http_manager.py \
  -k 'stateless_requests_memory_cleanup or stateless_termination_logs_debug_not_info'

Result: 2 passed

[km-anthropic]

@claude review

[dgenio]

The change is focused and correct. A few observations:

Code change: The conditional log level is the right approach — DEBUG for routine cleanup, INFO only for named session termination. The wording "Stateless request completed, cleaning up transport" is much clearer than "Terminating session: None".

Test: Well-structured and mirrors the existing test_stateless_requests_memory_cleanup pattern in the file. Using caplog.at_level(logging.DEBUG, ...) to capture the debug message is correct.

One minor nit: the del message in mock_send is a bit unusual — pass or ... is more idiomatic for a stub that just suppresses lint. Non-blocking though.

For context: #1696 / #1697 is a docs PR covering stateless mode semantics more broadly — this fix and that documentation would complement each other well for users trying to understand what stateless mode does and doesn't do.

[maxisbey]

Thanks for the PR, and sorry it sat here without a proper review.

We're closing most of the open PR backlog. v2 is out and changed a lot of the SDK, so many older PRs no longer apply as written, and we're a small team that realistically doesn't have the capacity to work through the rest.

If this still matters to you on v2, the most useful thing you can do is open an issue (or comment on the existing one) with your use case and a repro. Hearing why it matters to you is what we use to decide what to prioritise.

_{AI Disclaimer}