Parent: #1936
Problem
The self-host GitHub response cache (used for branch-protection, commit-ref, and repo/user/installation-metadata reads) derives its Redis cache key from a hash of the literal Authorization header value. Installation tokens rotate roughly hourly by design, plus early on any auth failure, plus (if the token isn't preserved across restarts) on every redeploy. Because the cache key is a hash of the token bytes rather than a stable identity, every rotation invalidates the ENTIRE cached-response namespace for that installation across all cache classes simultaneously — not just the entries that are actually stale. Given how frequently this stack redeploys in active development, a substantial share of the nominal cache TTL benefit is very plausibly being lost to this churn rather than genuine expiry.
Notably, an equivalent bug for a sibling credential (the GitHub App's own signing JWT) was already identified and fixed by reusing a minted JWT for part of its validity window specifically to keep its cache key stable — the same fix pattern was never applied to the longer-lived installation token.
Requirements
- Replace the token-hash-derived cache key with the already-existing stable per-installation identifier used elsewhere in the codebase for rate-limit admission scoping, for every call site where that identifier is available.
- Preserve correct isolation: different installations must never be able to read each other's cached responses.
- Identify and handle the one caller that currently authenticates with a shared public token rather than an installation token — it needs an equivalently stable, but distinctly-scoped, key so it doesn't collide with or leak into installation-scoped entries.
- No change to what gets cached or for how long — this is purely a key-derivation fix.
Deliverables
- Updated cache-key derivation using the stable installation/public-token identity already threaded through the codebase's admission-key plumbing, with a safe fallback for any caller that doesn't yet have one.
- Tests proving: a token rotation no longer invalidates the cache for an unrelated (or the same) installation's still-valid entries, cross-installation isolation is preserved, and the public-token caller is unaffected.
Acceptance criteria
- A simulated token rotation does not evict cache entries that are otherwise within their TTL.
- Two different installations' cached responses never collide.
- No behavior change to cache TTLs or what's eligible for caching.
Expected outcome
The existing branch-protection/commit/metadata caches actually deliver their full nominal TTL benefit instead of resetting on every token mint, compounding the benefit of every other caching fix in this roadmap.
Parent: #1936
Problem
The self-host GitHub response cache (used for branch-protection, commit-ref, and repo/user/installation-metadata reads) derives its Redis cache key from a hash of the literal
Authorizationheader value. Installation tokens rotate roughly hourly by design, plus early on any auth failure, plus (if the token isn't preserved across restarts) on every redeploy. Because the cache key is a hash of the token bytes rather than a stable identity, every rotation invalidates the ENTIRE cached-response namespace for that installation across all cache classes simultaneously — not just the entries that are actually stale. Given how frequently this stack redeploys in active development, a substantial share of the nominal cache TTL benefit is very plausibly being lost to this churn rather than genuine expiry.Notably, an equivalent bug for a sibling credential (the GitHub App's own signing JWT) was already identified and fixed by reusing a minted JWT for part of its validity window specifically to keep its cache key stable — the same fix pattern was never applied to the longer-lived installation token.
Requirements
Deliverables
Acceptance criteria
Expected outcome
The existing branch-protection/commit/metadata caches actually deliver their full nominal TTL benefit instead of resetting on every token mint, compounding the benefit of every other caching fix in this roadmap.