[harlan-zw]

🔗 Linked issue

Related to #525

❓ Type of change

• 📖 Documentation
• 🐞 Bug fix
• 👌 Enhancement
• ✨ New feature
• 🧹 Chore
• ⚠️ Breaking change

📚 Description

Two findings from the review of #525 and #526:

• A /gh page read waits at most GITHUB_PAGE_READ_TIMEOUT_MS (4 s) for GitHub. The installation token mint it waited for ignored that limit. If GitHub hung, each page read could wait the mint's own 15 s.
• The credential did not remember a failed mint. Every read tried a new mint, emitted another app-token-unavailable event, and then read with GITHUB_TOKEN.

What changes:

• readWithGithubCredential takes the read's deadline, an AbortSignal, and passes it to current() and renew(). The registry client passes the signal behind timeoutMs. A read waits for a mint no longer than its deadline. It then rejects with the deadline's reason, as its own request would. The sync and builds pass no deadline, so their mint keeps the 15 s limit.
• The deadline of the read that starts a mint also ends that mint. Such a cut-off says nothing about the App, so it opens no failure window. A read that waited on the same mint with time left mints again. A page read with 50 ms left cannot move the isolate to the fallback for a minute.
• A failed mint stands for 55 to 65 s in the isolate token cache. A refusal, a 5xx, a network fault and the 15 s limit all count. Reads in that window use the fallback and make no mint. The read that started the mint emits the one event. App secrets that do not parse also emit one app-misconfigured event per window, not one per read.
• A 401 on the cached token still drops it and mints once, even while a failure stands. The token worked, so the App may work again. Only the read that drops the token mints through the window. Other reads that held the token share that mint.

The runbook in docs/ops/artifact-delivery-rollout.md now describes the window and the deadline.

🤖 AI disclosure: Harlan Agent Kit modified this description. My AI open-source policy.