Horde.Registry-backed session registry for the Anubis MCP transports.

Why not Anubis.Server.Registry.PG

The bundled Anubis.Server.Registry.PG adapter does not implement the optional session_name/2 callback. When the transport resolves a session name, the fallback builds a dynamic atom from the client-supplied mcp-session-id:

:"#{registry_name}.session.#{session_id}"

Atoms are never garbage collected, so a client that walks distinct mcp-session-id values can exhaust the BEAM atom table and crash the node - a remote, unauthenticated denial of service. :pg also gives no cluster-wide name uniqueness, only process-group membership.

This adapter implements session_name/2, returning a :via tuple:

{:via, Horde.Registry, {registry_name, session_id}}

Because Anubis passes that name to the session GenServer.start_link/3, the session auto-registers in the CRDT-backed Horde.Registry on start. The session_id is kept as ETS/CRDT data, never converted to an atom, so the atom-exhaustion vector is closed. Horde gives cluster-wide name uniqueness and resolves a registered name to the owning (possibly remote) pid, so a request that lands on any node routes transparently to the node holding the session.

Anubis starts the session DynamicSupervisor itself, so this adapter only starts the Horde.Registry; cross-node request routing is handled by distributed Erlang GenServer.call/3 against the pid that Horde.Registry.lookup/2 returns, exactly as the :pg adapter relied on.

Wiring

{MyApp.MCP.Server,
 transport: :streamable_http,
 registry: {AttestoMCP.Anubis.Registry.Horde, []},
 # ...
}

Cluster membership uses members: :auto, so every node running the same Anubis registry name discovers its peers (pair it with a clustering library such as libcluster so the nodes connect).

Compile-guarded on Anubis.Server.Registry and Horde.Registry.