Bot Mode wake-ups died on a routing split-brain: session.resume /
session.activate / session.usage were dispatched on whatever socket was
active at request time, while the bot's own backend sat healthy and idle
(zero traffic until the idle reaper killed it). Two divergence sources,
both fixed:
1. Registry-owned route truth. applyActive() now publishes the active
route's bare profile ($activeGatewayRoute + onActiveRouteChanged), and
use-gateway-boot mirrors it into $activeGatewayProfile. Previously,
eviction fallbacks (idle reap, connection removal, profile delete)
moved the SOCKET back to the primary while the profile atom kept
naming the evicted bot — ensureGatewayProfile's "already active" fast
path then trusted the stale atom and skipped the re-swap forever.
2. Request-time routing for session-scoped RPCs. resumeSession's RPCs go
through requestForSessionProfile (store/session-request-router.ts):
when the active route serves the session's owning profile the ambient
dispatcher is kept (reauth-aware reconnect); when it diverges — a
concurrent switch won the mutex, a failed dial left the old socket
active, an eviction re-pointed the route — the RPC is pinned to the
owning profile's own socket via requestGatewayForProfile.
Diagnosed from zero trust's debug bundle (loki/hulk/teknium-kun backends
READY then idle-reaped, renderer stuck on "Waking up… → retries gave
up") and DanBennettUK's #89206 trace (profile socket accepts, closes
with messages=0, no resume RPC observed).
Both layers sabotage-proven: reverting the route publish fails the
lockstep/eviction tests; reverting the request-time routing fails the
wrong-socket dispatch test.
Teknium
ae6578aff8