fix: prevent "Server not initialized" race on first request

[dbrown2642]

Problem

On Streamable HTTP, the client sends notifications/initialized and its first request (e.g. tools/list) as two separate, near-simultaneous HTTP requests. The client sends them in order, but the transport doesn't guarantee order, so tools/list sometimes lands before the notification.

When it does, the session rejects it with "Server not initialized" (gate, error). A client that doesn't retry then stalls. In my case, the Claude Desktop client hangs ~30s, then sends notifications/cancelled.

The spec lets a client send requests as soon as the server responds to initialize, so this is stricter than the spec requires.

Solution

Mark the session initialized on the initialize response, not only in the notifications/initialized handler. Adds a test for a request arriving after initialize but before the notification.

Rationale

Matches the official SDKs, which mark the session ready on the initialize response:

• TypeScript (streamableHttp.ts#L501)
• Python (#1478)
• Rust (#788)

The spec says SHOULD NOT, not MUST NOT, so the notification isn't a hard gate.

[coderabbitai]

📝 Walkthrough

Marks Streamable HTTP sessions as initialized as soon as initialize completes, instead of waiting for notifications/initialized, so early client requests are accepted rather than rejected with “Server not initialized.” Adds a regression test covering a request that arrives after initialize but before the initialization notification.

Walkthrough

In the initialize request handler within lib/anubis/server/session.ex, the state update now includes initialized: true alongside client_capabilities. Previously, the session was only marked initialized after receiving a notifications/initialized notification. A new test in test/anubis/server/session_test.exs verifies that a tools/list request is processed successfully immediately after an initialize request, without waiting for the notification.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and clearly describes the race fix on first request.
Description check	✅ Passed	The description matches the template and includes Problem, Solution, and Rationale with concrete details.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

lib/anubis/server/session.ex (1)

669-675: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

P1: initialized: true now opens the gate before module.init/2 runs.

Lines 674-675 let the first post-initialize request/notification through, but the server setup callback still only runs in handle_notification("notifications/initialized") on Lines 891-915. That means the race fixed by this PR can now route work through handle_request/2 with a pre-init frame. The auto-init path already avoids this by calling maybe_call_init/3 before serving traffic, so the normal init path should do the same (or split “accept requests” from “server callback completed” into separate flags) to avoid this new boss fight.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3a2f2d3c-143a-4bdf-9f18-6cf950b951ea

📥 Commits

Reviewing files that changed from the base of the PR and between 2c641a0 and da0e33a.

📒 Files selected for processing (2)

• lib/anubis/server/session.ex
• test/anubis/server/session_test.exs