Construct a session manager with the default idle TTL and active-session cap, both bounding ConnectionState residency for abandoned sessions.
Construct with an explicit idle TTL and active-session cap. idleTtl Duration.zero disables the idle sweep; maxActive 0 disables the cap.
Number of currently-active sessions.
Generate a new cryptographically-secure session id, create and store the per-session ConnectionState it owns, record it as active, and return the id. The id is a 256-bit value rendered as lowercase hex, which satisfies the spec requirement that the id "MUST only contain visible ASCII characters (ranging from 0x21 to 0x7E)".
Whether id names a currently-active (non-terminated) session.
The ConnectionState this manager owns for the active session id, or null when the id is empty, unknown, or already terminated. The request path puts this on the request context so dispatch reads/writes only this session's per-connection state. Resolving a session refreshes its last-activity timestamp so an in-use session is never swept as idle.
Terminate id. Returns true if the session existed (and was removed, dropping its ConnectionState), false if it was unknown/already terminated.
Default idle TTL applied when none is configured: a stateful session left untouched for this long is swept on the next create.
Default cap on concurrently-active sessions, bounding worst-case ConnectionState residency for a server whose clients never issue DELETE.
Tracks active Streamable HTTP sessions for a server mount.
When session management is enabled (the server was built with McpServer.stateful, i.e. server.mode == ServerMode.stateful), the server assigns a cryptographically-secure Mcp-Session-Id on the response carrying the InitializeResult, requires that id on every subsequent request (HTTP 400 when absent, HTTP 404 when unknown/terminated), and supports client-driven termination via HTTP DELETE.
Concurrency: the SDK ships and is supported only on vibe.d's default single-threaded event loop, where requests are dispatched cooperatively on fibers of one thread and create/isActive/terminate are each a single synchronous associative-array operation with no intervening yield -- so they are race-free among fibers without locking, matching the single-fiber model the coordinators document (see mcp.transport.sse_context). Running the router with HTTPServerOption.distribute or worker threads is unsupported; all shared coordinator/session state would then need fiber-and-thread-aware locking.