* feat: add session-lifecycle conformance scenario for streamable HTTP
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 #79
Signed-off-by: Satoshi Ito <satoshi.ito.tf@hitachi.com>
* fix: address review feedback on session-lifecycle scenario
- Adapt run() to the RunContext signature introduced in #318.
- Send the protocol version the server negotiated in the initialize
result on follow-up requests instead of hardcoding 2025-11-25,
falling back to the requested spec version (the sse-multiple-streams
pattern from #415/#416). Parsing the initialize body is bounded by a
5s timeout, and every fetch shares one AbortController aborted when
the scenario ends, so a server answering with a never-ending SSE
stream can neither hang the run nor leak a held-open connection.
- Fail the scenario when initialize itself fails; previously a broken
server (401/500) was reported as stateless and passed.
- Check the initialized notification response and fail when it is
rejected, emitting SKIPPED placeholders for the lifecycle checks so
per-check aggregation keeps its rows.
- Report unexpected DELETE statuses as WARNING instead of FAILURE (the
spec never pins a success status for session termination).
- Treat 404 on DELETE as an already-terminated session only when the
follow-up request confirms the session is gone; a 404 from a server
whose session still responds (likely no DELETE route) is a WARNING
with the 404 check skipped, rather than a misattributed failure.
- Exclude the scenario from the draft spec version via removedIn:
sessions were removed entirely by SEP-2575.
---------
Signed-off-by: Satoshi Ito <satoshi.ito.tf@hitachi.com>
Co-authored-by: Paul Carleton <paulc@anthropic.com>
3531a64803