Summary
fetchAndStorePullRequestFilesForReview (src/github/backfill.ts, around line 2431) declares a
local warnings: string[] and passes it into fetchPullRequestFiles, which pushes a message like
"File sync failed for #N: GitHub REST and GraphQL detail fetches failed." into it when both the
REST and GraphQL fetch paths fail (fetchPullRequestFiles, same file, ~line 2385-2401). The caller
never reads warnings afterward — it's allocated, conditionally populated on a real failure, and
then discarded. The fail-safe return [] behavior itself is correct and intentional (documented on
the function), but the failure path that leads to it currently has zero observability: no
console.log/console.error, no metric, no audit row.
Area
GitHub backfill
Expected behavior
When both the REST and GraphQL file-fetch attempts fail for a PR during the inline review-files
fetch, that failure should leave a structured, greppable trace — matching the
console.error(JSON.stringify({ level: "warn", event: ..., ... })) convention already used
throughout src/ (for example review_files_inline_fetch_failed in
src/queue/processors.ts) — so the failure rate is visible in production logs instead of only in
DB state.
Actual behavior
The warnings array is populated on failure but never read by
fetchAndStorePullRequestFilesForReview. The only related log line, review_files_inline_fetch_failed
in src/queue/processors.ts's getPullRequestFilesForReview, fires solely when the whole call
throws — which it structurally can't, since every fallible step inside
fetchAndStorePullRequestFilesForReview and fetchPullRequestFiles already degrades via its own
.catch()/fallback rather than throwing. So the actual "REST and GraphQL both failed" case — the one
warnings exists to record — currently fails completely silently into an empty file list, with no
log trace anywhere.
Reproduction
Call fetchAndStorePullRequestFilesForReview(env, repoFullName, pullNumber, token) for a PR where
both GET /pulls/:number/files and the GraphQL PR-detail fallback fail (REST returns non-2xx and the
GraphQL query also fails/throws). The function correctly returns [], but nothing is logged.
Validation
Not yet fixed — filing before implementing the log-only fix (add a console.error(JSON.stringify({level: "warn", ...})) when warnings.length > 0, no change to the fail-safe return value).
Public-safety check
Summary
fetchAndStorePullRequestFilesForReview(src/github/backfill.ts, around line 2431) declares alocal
warnings: string[]and passes it intofetchPullRequestFiles, which pushes a message like"File sync failed for #N: GitHub REST and GraphQL detail fetches failed."into it when both theREST and GraphQL fetch paths fail (
fetchPullRequestFiles, same file, ~line 2385-2401). The callernever reads
warningsafterward — it's allocated, conditionally populated on a real failure, andthen discarded. The fail-safe
return []behavior itself is correct and intentional (documented onthe function), but the failure path that leads to it currently has zero observability: no
console.log/console.error, no metric, no audit row.Area
GitHub backfill
Expected behavior
When both the REST and GraphQL file-fetch attempts fail for a PR during the inline review-files
fetch, that failure should leave a structured, greppable trace — matching the
console.error(JSON.stringify({ level: "warn", event: ..., ... }))convention already usedthroughout
src/(for examplereview_files_inline_fetch_failedinsrc/queue/processors.ts) — so the failure rate is visible in production logs instead of only inDB state.
Actual behavior
The
warningsarray is populated on failure but never read byfetchAndStorePullRequestFilesForReview. The only related log line,review_files_inline_fetch_failedin
src/queue/processors.ts'sgetPullRequestFilesForReview, fires solely when the whole callthrows — which it structurally can't, since every fallible step inside
fetchAndStorePullRequestFilesForReviewandfetchPullRequestFilesalready degrades via its own.catch()/fallback rather than throwing. So the actual "REST and GraphQL both failed" case — the onewarningsexists to record — currently fails completely silently into an empty file list, with nolog trace anywhere.
Reproduction
Call
fetchAndStorePullRequestFilesForReview(env, repoFullName, pullNumber, token)for a PR whereboth
GET /pulls/:number/filesand the GraphQL PR-detail fallback fail (REST returns non-2xx and theGraphQL query also fails/throws). The function correctly returns
[], but nothing is logged.Validation
Not yet fixed — filing before implementing the log-only fix (add a
console.error(JSON.stringify({level: "warn", ...}))whenwarnings.length > 0, no change to the fail-safe return value).Public-safety check
included above.