An agent stores a GitHub App installation token in its working memory at the start of a long-running workflow. GitHub App installation tokens expire after 1 hour. The workflow is expected to run for 2 hours. At the 70-minute mark, the agent attempts a GitHub API call and receives a 401 Unauthorized response. What is the CORRECT recovery pattern for this scenario?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A stale token in memory is like trying to pay with an expired credit card — the fix isn't to quit buying groceries. Option B is correct: detect the 401 as a token expiry event, refresh the token using your GitHub App credentials, update working memory, and retry. Token refresh for long-running workflows is a first-class engineering concern, not an error condition.
Full explanation below image
Full Explanation
The correct answer is B. GitHub App installation tokens are intentionally short-lived (1 hour) as a security feature — they limit the blast radius if a token is compromised. For agents running workflows longer than 1 hour, the correct design is to treat token expiration as an expected operational event, not a failure. The recovery pattern: (1) detect the 401 status code and check if it indicates token expiration (GitHub returns a specific error body), (2) use the GitHub App's private key to generate a new JWT and exchange it for a fresh installation token, (3) update the token value in working memory, and (4) retry the API call that originally failed. The workflow continues without user involvement.
Option A is wrong because terminating on a 401 after 70 minutes wastes the completed work and provides a poor user experience for a predictable, recoverable condition. Token expiration in a 2-hour workflow is not an unexpected failure — it was foreseeable at design time and should be handled automatically.
Option C is wrong because switching to a PAT mid-workflow is a security downgrade. GitHub App installation tokens are scoped to the specific repositories and permissions of the installation, providing fine-grained least-privilege access. A PAT typically carries broader permissions tied to a user account, violating least-privilege principles. Additionally, using a PAT stored in a secret for this fallback conflates two separate authentication mechanisms and complicates the security model.
Option D is wrong because exponential backoff is the correct pattern for transient failures (network blips, rate limits, temporary server errors), not for authentication failures. Retrying a 401 without refreshing the token will always return another 401 — the token does not become valid again with time. Backoff retries on an auth error waste time and API quota.