Module refresh 

Single-flight refresh coordination for upstream OAuth clients.

RefreshLocks prevents concurrent callers for the same (upstream, subject) pair from issuing simultaneous token refresh requests against the authorization server. One caller wins the lock and executes get_access_token() (which internally handles proactive refresh); all others wait and then return the already-refreshed token.

Scope: This module handles proactive refresh triggered before making an MCP call. Reactive 401-retry logic is wired in Task 4 (dispatch/gateway/).

rmcp refresh semantics

AuthorizationManager::get_access_token() refreshes the token when fewer than 30 s remain before expiry. It does not react to 401 responses from the resource server. A 401 with a locally-still-valid token requires an explicit refresh_token() call followed by a retry — that is the Task 4 responsibility.

Structs

RefreshFailureCache

Per-(upstream_name, subject) “is this credential known-broken right now” cache.

RefreshLocks

Per-(upstream_name, subject) mutex pool.

Constants

REFRESH_FAILURE_COOLDOWN

How long a confirmed refresh failure suppresses further live retries for the same (upstream, subject) pair. Chosen to be well short of any human patience window (so a fix shows up promptly) while still cutting a dead credential’s call volume against the authorization server by roughly two orders of magnitude versus retrying on every single request.