fix(streamable_http): restore session from store on notif/resp registry miss (multi-instance)

[mariamaman]

Problem

In a horizontally scaled (multi-instance) Streamable-HTTP deployment where nodes are not clustered (no distributed Erlang between instances — common on Cloud Run / serverless), MCP session state held in Registry.Local (node-local ETS) is invisible to other instances.

The request path already handles this: handle_request_message/5 → find_or_create_session/3, which on a registry miss starts a session and, when a Session.Store is configured, restores it via maybe_restore_from_store/1.

But handle_notification_message/5 and handle_response_message/5 call find_session/2 (registry only) and return 404 "Session not found" on a miss — they never consult the configured Session.Store.

Observed failure

1. initialize (no session id) → instance A creates + persists the session, returns mcp-session-id.
2. notifications/initialized (session id present) → load-balanced to instance B → registry miss → 404, notification lost.

This is intermittent and instance-correlated, and it breaks clients (e.g. the claude.ai MCP connector) that treat the handshake-notification 404 as a fatal transport error — even though a Session.Store (Redis/DB) is configured.

Fix

Make handle_notification_message and handle_response_message resolve-or-restore from the store on a registry miss, mirroring what the request path already does. When no store is configured (single node), behaviour is unchanged: a registry miss stays a 404.

The patch adds find_or_restore_session/2: on a registry miss, if the session exists in Anubis.get_session_store_adapter(), restore it via the existing start_and_auto_initialize_session/2; otherwise keep the 404 (so genuinely-missing sessions still 404 rather than being masked).

Notes

• Small, localized change in streamable_http/plug.ex; reuses existing start_and_auto_initialize_session/2.
• Pairs naturally with the Session.Store docs, which already recommend a store for multi-node deployments — this closes the gap where the store isn't consulted on the notif/resp paths.

Branch/commit: mollowai/anubis-mcp@mollow/mcp-notif-resp-store-restore (based on v1.6.1).

[coderabbitai]

📝 Walkthrough

Problem

Session requests can fail on multi-instance deployments when the session is not in the local registry.

Solution

Restore sessions from the configured Session.Store for notification and response requests.

Rationale

Preserves single-node 404 behavior while allowing valid sessions routed across instances to succeed.

Walkthrough

Notification and response message handling now use find_or_restore_session/2. When a local registry lookup misses, the Plug checks the configured session store, starts and auto-initializes a session when stored data exists, and continues processing. If no store is configured or no session is found, it preserves the existing not-found response.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely describes restoring Streamable HTTP sessions from store on registry misses in multi-instance deployments.
Description check	✅ Passed	The description covers the problem, fix, and rationale well, with only minor template heading differences from the required structure.
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/transport/streamable_http/plug.ex (1)

191-216: 🩺 Stability & Availability | 🔴 Critical | ⚡ Quick win

P1: Handle unexpected restoration errors to prevent a CaseClauseError crash.

Because start_and_auto_initialize_session/2 can return an {:error, reason} tuple (e.g., if auto-initialization fails or the process fails to start), passing that back through find_or_restore_session/2 will trigger a sneaky CaseClauseError here since we only match {:ok, session_pid} and {:error, :not_found}.

Let's add a catch-all error clause to log the failure and gracefully return an HTTP 500 instead of completely crashing the Plug process 😎.

🛠️ Proposed fix to handle restoration errors

     defp handle_notification_message(conn, message, session_id, context, opts) do
       case find_or_restore_session(opts, session_id) do
         {:ok, session_pid} ->
           GenServer.cast(session_pid, {:mcp_notification, message, context})
 
           conn
           |> put_resp_content_type("application/json")
           |> send_resp(202, "{}")
 
         {:error, :not_found} ->
           send_error(conn, 404, "Session not found")
+
+        {:error, reason} ->
+          Logging.transport_event("session_restore_failed", %{reason: inspect(reason)}, level: :error)
+          send_error(conn, 500, "Failed to restore session")
       end
     end
 
     defp handle_response_message(conn, message, session_id, context, opts) do
       case find_or_restore_session(opts, session_id) do
         {:ok, session_pid} ->
           GenServer.cast(session_pid, {:mcp_response, message, context})
 
           conn
           |> put_resp_content_type("application/json")
           |> send_resp(202, "{}")
 
         {:error, :not_found} ->
           send_error(conn, 404, "Session not found")
+
+        {:error, reason} ->
+          Logging.transport_event("session_restore_failed", %{reason: inspect(reason)}, level: :error)
+          send_error(conn, 500, "Failed to restore session")
       end
     end

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 80feb8bb-a7ae-4aca-8903-13c72c5601f9

📥 Commits

Reviewing files that changed from the base of the PR and between 3b636a8 and af4ccdc.

📒 Files selected for processing (1)

• lib/anubis/server/transport/streamable_http/plug.ex

[zoedsoupe]

please, merge the main to correctly continue from #208

The merge-base changed after approval.

[zoedsoupe]

hey, i've messed with the history but i've fixed it and manually merged your contribution. so sorry for that and thanks again for the contribution