Expand description
Session state for the MCP daemon.
Each connected client (one external CLI process) creates a session via
POST /session, receives a { session_id, token } pair, and attaches
both headers on every JSON-RPC call. Sessions hold their own cwd and
some future-proof scaffolding (allowed-tools filter, created-at stamp).
Storage is a tokio::sync::RwLock<HashMap<...>> — Send+Sync, no deps.
§Session-wide progress broadcast (M4)
In addition to the per-request SSE stream that /mcp tools/call uses to
ship progress events back to the caller, we also publish each event onto
a per-session tokio::sync::broadcast channel. Any subscriber holding
the session token can tap that stream via GET /session/<id>/events to
observe every Construct tool’s progress for that session in real time —
which is how the V2 Code tab surfaces “what Construct is doing right now”
while an external CLI is mid tools/call.
Broadcast capacity is small (64). Slow consumers simply miss frames
(broadcast::Receiver returns Lagged); progress events are advisory,
never load-bearing for correctness.
Structs§
- Progress
Event - Session-wide progress event published to any subscriber of
/session/<id>/events. Mirrors the per-requestnotifications/progresspayload with additionaltool+timestampfields so subscribers can render “Notion — 4/10 at 10:20:33” without having to correlate tokens back to the originating request. - Session
State - Session
Store