bug: context.add RPC does not update in-memory dispatch state #47

New issue

Open

opened 2026-05-11 13:32:57 +00:00 by casper-stevens · 0 comments

casper-stevens commented

2026-05-11 13:32:57 +00:00

Member

Summary

context.add persists a new context to the registry file but does not update the in-memory context_names vec or type_dispatch map in UnifiedServerBuilder. Contexts added at runtime via RPC silently do not work — requests for the new context are filtered out and fall back to root.

Root cause

In crates/server/src/server/unified_server.rs, context_names and type_dispatch are built once at serve() time. The context.add RPC handler only writes to the registry — type_dispatch and context_names are NOT updated.

The context resolution in dispatch_rpc filters hero_context_name against state.context_names — which never got the new entry — and falls through to integer lookup, landing on root.

Impact

No error is returned. Data silently comes back from the wrong context. The server must be restarted with the new context in the --contexts flag for it to take effect.

Discovered via

Debugging context switching in hero_biz — contacts appeared identical across all contexts despite correct header forwarding all the way through.

Fix options

Proper: When context.add is called, register domain handlers for the new context and update context_names and type_dispatch in place.
Interim: Return an error from context.add saying a restart with --contexts is required, so callers are not silently misled.

## Summary context.add persists a new context to the registry file but does not update the in-memory context_names vec or type_dispatch map in UnifiedServerBuilder. Contexts added at runtime via RPC silently do not work — requests for the new context are filtered out and fall back to root. ## Root cause In crates/server/src/server/unified_server.rs, context_names and type_dispatch are built once at serve() time. The context.add RPC handler only writes to the registry — type_dispatch and context_names are NOT updated. The context resolution in dispatch_rpc filters hero_context_name against state.context_names — which never got the new entry — and falls through to integer lookup, landing on root. ## Impact No error is returned. Data silently comes back from the wrong context. The server must be restarted with the new context in the --contexts flag for it to take effect. ## Discovered via Debugging context switching in hero_biz — contacts appeared identical across all contexts despite correct header forwarding all the way through. ## Fix options 1. Proper: When context.add is called, register domain handlers for the new context and update context_names and type_dispatch in place. 2. Interim: Return an error from context.add saying a restart with --contexts is required, so callers are not silently misled.