fix: SessionRegistryMiddleware compatible with MCP SDK 1.27.0 SSE

[cmeans-claude-dev]

Summary

• Root cause: MCP SDK 1.27.0 changed initialize responses from JSON to SSE (text/event-stream). The middleware's replay_receive returned synthetic http.disconnect after body replay, causing EventSourceResponse to abort before sending headers (500 error)
• _buffer_body: forwards to real receive after replay instead of synthetic disconnect
• _handle_subsequent: streams 2xx responses immediately (SSE-safe), only buffers errors for re-init interception
• _reinitialize: init_receive/replay_receive block with anyio.sleep(3600) loop instead of faking disconnect

Fixes #176.

QA

Prerequisites

• pip install -e ".[dev]"
• Deploy to test instance on alternate port (AWARENESS_PORT=8421) with AWARENESS_SESSION_DATABASE_URL set

Manual tests (via MCP tools)

1. • Initialize with session registry — SSE init test verifies 200 with text/event-stream and session registered
2. • Subsequent request — SSE subsequent test verifies streaming response passes through
3. • Cross-node re-init — SSE re-init test verifies 3-call flow (400 → init → replay) with SSE responses
4. • Claude.ai connection — requires production/staging deployment
5. • 725 tests pass — pytest tests/ — 725 passed

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cmeans]

Adding QA Active — reviewing SSE compatibility fix.

[cmeans]

QA Review — Round 1

Critical fix for MCP SDK 1.27.0 SSE compatibility. The three changes are well-targeted:

1. _buffer_body — forwards to real receive() after replay instead of synthetic disconnect. Prevents EventSourceResponse from aborting.
2. _handle_subsequent — 2xx streams immediately (SSE-safe), errors buffered for re-init. Clean split.
3. _reinitialize — init_receive/replay_receive block with anyio.sleep(3600) loop instead of returning disconnect.

SSE test stubs faithfully reproduce the EventSourceResponse task group pattern (stream + disconnect listener), which validates the fix against the actual failure mode.

Checks

Check	Result
57/57 session tests pass	✅
725/725 full suite pass	✅
README test count matches (725)	✅
CHANGELOG entry present	✅
CI all green	✅

Findings

1. [Substantive] CHANGELOG says anyio.sleep_forever() but code uses while True: await anyio.sleep(3600)

The CHANGELOG entry reads "uses anyio.sleep_forever() for disconnect detection" but the actual code uses while True: await anyio.sleep(3600). Either update the CHANGELOG to match the code, or use anyio.sleep_forever() in the code (which would be cleaner — single call, no loop).

PR checkboxes

4/5 checked. Test 4 (Claude.ai connection) requires production deployment.

Verdict

Finding #1 is doc drift — CHANGELOG doesn't match code. Everything else is clean.

[cmeans]

Applying QA Failed — CHANGELOG says anyio.sleep_forever() but code uses anyio.sleep(3600) loop. Fix either to match the other.

[cmeans-claude-dev]

Dev response

QA finding: CHANGELOG says sleep_forever but code uses sleep loop

• Fixed in 6d111e2 — CHANGELOG updated to say "blocks until task group cancellation" instead of referencing anyio.sleep_forever()

Ready for re-review.

[cmeans]

QA Review — Round 2

CHANGELOG fixed — now says "blocks until task group cancellation" instead of naming anyio.sleep_forever(). Matches the actual implementation. CI green. Zero findings. Verdict: Pass.

[cmeans]

Applying Ready for QA Signoff — CHANGELOG fixed, CI green, zero findings.

[cmeans]

LGTM