muster release v5.28.0
Added
Awaiting Session: a per-session server’s state says whether it works. An MCPServer whose callers bring their own identity (auth.forwardToken, auth.tokenExchange) holds no connection of its own and, with no session connected, read Auth Required – the same state as a server waiting for a person to sign in through muster, and the same state whether every exchange succeeded or none could. Such a server now reads Awaiting Session (service state awaiting_session, Normal event MCPServerAwaitingSession) wherever it read Auth Required before: after the probe, after the last session’s connection is lost, after an automatic recovery reached it; Auth Required keeps its one meaning. A tokenExchange server verifies its client credentials Secret at start and is Failed with the Secret named while it is missing, retried with the reconnect backoff so a Secret that arrives later heals it. Every per-user exchange the aggregator performs reaches the server’s state: a failure every caller shares (the credentials Secret, invalid_client, a token endpoint that does not answer or answers 5xx, an unknown connector) puts the server in Failed with the exchange error as lastError, and the next successful exchange, a restart or a spec change returns it to Awaiting Session; a failure of the caller’s own token stays that session’s. The reconciler writes a Ready condition for every server whose reason names the state (AwaitingSession, Connected, AuthRequired, Suspended, …) or the class of an exchange failure (TokenExchangeCredentials, TokenExchangeEndpoint, TokenExchangeConnector) and whose message explains it – for Awaiting Session the mechanism, the token endpoint and connector, and when the last exchange succeeded. muster list mcpserver, core_service_status, the CRDs of both charts and the reference docs carry the state; core_service_start and core_service_restart on such a server say what it waits for instead of pointing at a sign-in that does not exist. The scenario oauth-sso-token-exchange-state pins the states through a real RFC 8693 exchange against the harness’s authorization server. (#1300)
