Parent: #1936
Problem
GITHUB_CACHE_TTL_SECONDS (threaded into createRedisResponseCache as the fallback ttlSeconds in src/selfhost/redis-response-cache.ts) is dead in production: every real call site into GitHubResponseCache.set() always passes an explicit ttlOverrideSeconds, so ttlOverrideSeconds ?? ttlSeconds never falls through to the configured value.
src/github/client.ts and src/github/graphql-cache.ts both always supply a 3rd argument, resolved from separate per-class env vars (GITHUB_BRANCH_PROTECTION_CACHE_TTL_SECONDS, GITHUB_COMMIT_CACHE_TTL_SECONDS, GITHUB_METADATA_CACHE_TTL_SECONDS, GITHUB_GRAPHQL_CACHE_TTL_SECONDS) that ignore GITHUB_CACHE_TTL_SECONDS entirely. A self-host operator who sets GITHUB_CACHE_TTL_SECONDS=5 (wanting fresher data) or =120 (wanting more aggressive caching), per .env.example's own documentation ("Short default Redis TTL for safe GitHub GET response caching. Set 0 to disable.") and docker-compose.yml's default wiring, gets no change in actual TTL behavior — only the >0/=0 enable/disable gate has any effect. A stale comment in src/server.ts ("Short-TTL cache ... Default 20s") reinforces the false impression that 20s governs freshness, when real entries live 10-20 minutes.
Fix
Either:
- Remove the unused
ttlSeconds parameter/env var and update .env.example + docker-compose.yml + the server.ts comment to stop advertising a knob that does nothing, OR
- Wire
GITHUB_CACHE_TTL_SECONDS in as the actual default that githubResponseCacheTtlSeconds()/githubGraphQlCacheTtlSeconds() fall back to when their own per-class env vars are unset, so the documented operator-facing setting is load-bearing again.
Option 2 preserves the documented operator-facing contract; option 1 is simpler. Pick one deliberately rather than leaving the current half-documented, non-functional state.
Verification
Parent: #1936
Problem
GITHUB_CACHE_TTL_SECONDS(threaded intocreateRedisResponseCacheas the fallbackttlSecondsinsrc/selfhost/redis-response-cache.ts) is dead in production: every real call site intoGitHubResponseCache.set()always passes an explicitttlOverrideSeconds, sottlOverrideSeconds ?? ttlSecondsnever falls through to the configured value.src/github/client.tsandsrc/github/graphql-cache.tsboth always supply a 3rd argument, resolved from separate per-class env vars (GITHUB_BRANCH_PROTECTION_CACHE_TTL_SECONDS,GITHUB_COMMIT_CACHE_TTL_SECONDS,GITHUB_METADATA_CACHE_TTL_SECONDS,GITHUB_GRAPHQL_CACHE_TTL_SECONDS) that ignoreGITHUB_CACHE_TTL_SECONDSentirely. A self-host operator who setsGITHUB_CACHE_TTL_SECONDS=5(wanting fresher data) or=120(wanting more aggressive caching), per.env.example's own documentation ("Short default Redis TTL for safe GitHub GET response caching. Set 0 to disable.") anddocker-compose.yml's default wiring, gets no change in actual TTL behavior — only the>0/=0enable/disable gate has any effect. A stale comment insrc/server.ts("Short-TTL cache ... Default 20s") reinforces the false impression that 20s governs freshness, when real entries live 10-20 minutes.Fix
Either:
ttlSecondsparameter/env var and update.env.example+docker-compose.yml+ theserver.tscomment to stop advertising a knob that does nothing, ORGITHUB_CACHE_TTL_SECONDSin as the actual default thatgithubResponseCacheTtlSeconds()/githubGraphQlCacheTtlSeconds()fall back to when their own per-class env vars are unset, so the documented operator-facing setting is load-bearing again.Option 2 preserves the documented operator-facing contract; option 1 is simpler. Pick one deliberately rather than leaving the current half-documented, non-functional state.
Verification
src/selfhost/redis-response-cache.ts,src/github/client.ts,src/github/graphql-cache.ts(line numbers may have shifted).GITHUB_CACHE_TTL_SECONDSeither has no effect (documented) or does have effect (wired).