Summary
The Rust SDK handles gitHubToken.getToken by awaiting GitHubTokenRegistry::dispatch directly inside SessionRouter's single request-routing loop.
Because the registered token provider is user-supplied async code, a slow or indefinitely pending callback prevents the router from dispatching unrelated CLI-to-SDK requests across every session owned by that client. A provider panic can also terminate the routing task, leaving subsequent requests unanswered.
This path was introduced with the session-scoped GitHub token provider support in #2412.
Expected behavior
Token acquisition should be isolated from the global routing loop so one provider cannot stall unrelated sessions or request types. Provider panics should be contained and returned to the corresponding JSON-RPC request as an internal error rather than terminating request routing.
The implementation should preserve intentional ordering/concurrency semantics for requests targeting the same provider or session.
Suggested coverage
- A pending token callback does not prevent an unrelated request from being routed.
- A panicking token callback receives an error response.
- Request routing remains operational after a provider panic.
Summary
The Rust SDK handles
gitHubToken.getTokenby awaitingGitHubTokenRegistry::dispatchdirectly insideSessionRouter's single request-routing loop.Because the registered token provider is user-supplied async code, a slow or indefinitely pending callback prevents the router from dispatching unrelated CLI-to-SDK requests across every session owned by that client. A provider panic can also terminate the routing task, leaving subsequent requests unanswered.
This path was introduced with the session-scoped GitHub token provider support in #2412.
Expected behavior
Token acquisition should be isolated from the global routing loop so one provider cannot stall unrelated sessions or request types. Provider panics should be contained and returned to the corresponding JSON-RPC request as an internal error rather than terminating request routing.
The implementation should preserve intentional ordering/concurrency semantics for requests targeting the same provider or session.
Suggested coverage