Recover agent from expired gRPC access token#6727
Open
OfficialOzzy wants to merge 2 commits into
Open
Conversation
The agent stored its gRPC access token as a plain string refreshed only on a 30-minute timer. When the server rejected a token with codes.Unauthenticated (typically because it expired), there was no recovery path: the error was classified as permanent, so the agent's RPC loops kept retrying with the dead token and could orphan queued workflows. The token field was also read and written across goroutines without synchronization. This makes token access concurrency-safe and adds on-demand re-authentication: - AuthInterceptor guards the token with a RWMutex and exposes Token() and a new RefreshToken(ctx, staleToken) that serializes re-auth (refreshMu) and dedups concurrent callers via the stale-token check to avoid an auth stampede. - The RPC client gains an optional tokenRefresher (SetAuthRefresher). On codes.Unauthenticated, withAuthRefresh re-authenticates and lets backoff retry with the fresh token, bounded by maxAuthRefreshes so a genuinely bad secret cannot loop forever. classifyRPCErr now treats Unauthenticated as retryable; with no refresher configured it stays permanent (previous behavior). Adds regression tests: expired-token recovery over an in-process gRPC server, concurrent-refresh dedup, refresh exhaustion, and a token-access race test. Closes woodpecker-ci#4144 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6543
reviewed
Jun 15, 2026
|
|
||
| // refreshMu serializes re-authentication so that a burst of RPCs failing | ||
| // with an expired token does not trigger a stampede of Auth calls. | ||
| refreshMu sync.Mutex |
Member
There was a problem hiding this comment.
why have two mutex, can we just have accessTokenLock ?
Member
|
... so the agent's RPC loops (next(), report_health(), workflow init/wait, …) kept retrying with the dead token and never recovered ... in case the agent got deleted server side, the agent should not retry but exits with error ... we should handle that case propperly too!! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes an issue where an agent could get permanently stuck using an expired gRPC access token.
The agent stored its access token as a plain string refreshed only on a 30-minute timer. When the server rejected a token with
codes.Unauthenticated(typically because it expired), there was no recovery path: the error was classified as permanent, so the agent's RPC loops (next(),report_health(), workflow init/wait, …) kept retrying with the dead token and never recovered, orphaning queued/pending workflows. The token field was also read and written across goroutines without synchronization.Changes
agent/rpc/auth_interceptor.go— the access token is now guarded by async.RWMutex(Token()/setToken()). A new exportedRefreshToken(ctx, staleToken)forces re-authentication; arefreshMuserializes it with the background refresh timer, and thestaleTokencheck collapses a burst of concurrent refreshes into a singleAuthcall (no stampede). No token material is logged.agent/rpc/client_grpc.go— new optionaltokenRefresherwired viaSetAuthRefresher.classifyRPCErrnow treatscodes.Unauthenticatedas retryable, andwithAuthRefreshre-authenticates and lets backoff retry with the fresh token, bounded bymaxAuthRefreshesso a genuinely bad/revoked secret cannot loop forever (even with an infinite connection-retry timeout). When no refresher is configured the code stays permanent — preserving previous behavior.cmd/agent/core/agent.go— wires the auth interceptor into the client.Behavior / config
No public configuration changes. The existing 30-minute refresh timer still handles the normal case; this adds a reactive safety net for cases the timer path missed (e.g. server restart during a refresh window).
Tests
TestExpiredTokenRecovery— over an in-process gRPC server, an agent starting with a rejected (expired) token re-authenticates and the retried RPC succeeds.TestRefreshTokenDedup— concurrent refreshes sharing a stale token collapse into a single re-auth.TestWithAuthRefresh— recovery-after-refresh, give-up-after-budget, refresh-failure-stays-retryable, non-auth-errors pass through, nil-refresher stays permanent.TestAuthInterceptorTokenConcurrency— token access is race-free under-race.All pass under
make test-agentandmake lint(golangci-lint) is clean.Closes #4144