feat: add session-lifecycle conformance scenario for streamable HTTP#322
Open
pugsatoshi wants to merge 1 commit into
Open
feat: add session-lifecycle conformance scenario for streamable HTTP#322pugsatoshi wants to merge 1 commit into
pugsatoshi wants to merge 1 commit into
Conversation
This commits a `server-session-lifecycle` scenario that verifies the server honors the two RFC 2119 statements the Streamable HTTP transport spec places on session termination: 1. After receiving an HTTP DELETE bearing the issued Mcp-Session-Id, the server accepts it (2xx) or signals that explicit termination is not supported (405). 2. Subsequent requests bearing the terminated session ID MUST get HTTP 404 Not Found. The scenario inlines a raw `fetch` initialize/terminate/probe flow so the DELETE is the test action (not background cleanup). Stateless servers that never issue a session ID are reported as INFO, and the lifecycle checks are SKIPPED. Servers that return 405 on DELETE skip both checks without flagging a failure — the spec allows servers to refuse explicit termination. Refs modelcontextprotocol#79 Signed-off-by: Satoshi Ito <satoshi.ito.tf@hitachi.com>
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request adds a new
server-session-lifecycleconformance scenario that verifies the two server-side guarantees the Streamable HTTP transport spec places on session termination: (a) the server accepts (or 405s) an HTTP DELETE bearing the issuedMcp-Session-Id, and (b) subsequent requests bearing the terminated session ID get HTTP 404 Not Found.It also corrects a related spec deviation in the example
everything-server.ts, where stale/unknown session IDs were returning HTTP 400 instead of 404.Motivation and Context
Refs #79.
Issue #79 asked for two things. The first (the conformance harness should clean up its sessions after a run) is handled by PR 316. This PR addresses the second half —
there should probably be a conformance test for session lifecycle!— by adding a dedicated scenario that exercises DELETE + 404-on-terminated-session end-to-end.While developing the scenario, I noticed that the example server (
examples/servers/typescript/everything-server.ts) returned HTTP 400 for requests bearing a stale or unknownMcp-Session-Id, which violates the spec's "MUST 404" requirement.Without that fix, the new scenario would have failed in
all-scenarios.test.ts, so the two changes are bundled in the same PR.How Has This Been Tested?
npm run check— typecheck + lint pass.npm run test— 219/219 tests pass. The newsession-lifecycle.test.tscovers four cases: stateless server (INFO + SKIPPED), happy path (DELETE 200 → POST 404), DELETE-not-supported (405 → both SKIPPED), and the regression case (server returns 200 for a terminated session — Check B FAILURE).examples/servers/typescript/everything-server.ts:$ PORT=3011 npx tsx examples/servers/typescript/everything-server.ts &
$ npx tsx src/index.ts server --url http://localhost:3011/mcp --scenario server-session-lifecycle
Running client scenario 'server-session-lifecycle' against server: http://localhost:3011/mcp
Checks:
2026-05-25T02:25:16.795Z [server-session-delete-accepted ] SUCCESS Server accepts HTTP DELETE on the issued session ID with a 2xx response
2026-05-25T02:25:16.798Z [server-session-terminated-returns-404] SUCCESS Server returns HTTP 404 for requests bearing a
terminated session ID
Test Results:
Passed: 2/2, 0 failed, 0 warnings
The server logs the expected
Session initialized with ID: .../Received session termination request for session .../Session ... closedsequence.Breaking Changes
Downstream SDK conformance suites may surface failures on the new
server-session-delete-acceptedorserver-session-terminated-returns-404checks if their server returns 400 (or some other status) for a stale/unknownMcp-Session-Id.The scenario is intentionally lenient compared to the spec (servers MAY refuse DELETE outright with 405, in which case both checks are SKIPPED), so the only way to fail is the specific “DELETE accepted, but subsequent POST does not return 404” misbehavior.
SDKs that hit this can add the check IDs to their
expected-failuresbaseline as a temporary measure until they implement the spec.Types of changes
Checklist
Additional context