Self-Healing CI: Recovering a Briefly-Expired Registry Auth Token
A registry operation that fails as "unauthorized" on a short-lived token that just expired needs a fresh token, not new credentials -- re-authenticating and retrying clears it.
The problem
A registry push or pull fails with 401 Unauthorized because a short-lived auth token expired between login and use -- common on long jobs that authenticate early and push late. The underlying credentials are valid; the token simply aged out. A human re-authenticates and re-runs the step and it succeeds unchanged.
unauthorized: authentication required
# or
denied: token has expired; please re-authenticateWhy it happens
Many registries issue short-lived tokens from a login step. On a long job, the token can expire between when the job authenticated and when it actually pushes or pulls, so a valid credential produces a transient 401 purely because of timing.
It is a token-lifetime issue, not a permissions problem: the credentials still grant access, and refreshing the token before the operation makes the same push or pull succeed.
The manual fix
The manual fix is to refresh the token and retry:
- Re-authenticate to the registry immediately before the push/pull.
- Move the login step closer to the operation that uses it on long jobs.
- Re-run the job so a fresh token is issued.
How this gets automated
A briefly-expired token has a recognizable signature -- a 401 on credentials that are valid -- and a well-defined remedy: refresh the token and retry. A self-healing CI pipeline detects the auth-expiry condition, re-authenticates, retries the operation, and only escalates if the credentials are genuinely rejected, distinguishing an expired token from a real permissions problem.