Repository navigation
fix(scheduler): same-repository status read fails without statuses permission #2120
Description
Confirmed failure
Paper consumer ContextualWisdomLab/late-life-anxiety-reanalysis PR10 head 3d1e3ae56e3ef6ca0a995b6082c4f4a13629e0f6, scheduler run 34698738407/job103566634488, 2026-09-12 14:23:36 UTC:
gh api repos/ContextualWisdomLab/late-life-anxiety-reanalysis/commits/3d1e3ae56e3ef6ca0a995b6082c4f4a13629e0f6/status
Resource not accessible by integration (HTTP 403)
The full job log identifies trusted workflow/source SHA fb17ef556f94f673234aa557254ae52779e9a7b0. At that exact SHA, .github/workflows/pr-review-merge-scheduler.yml:119 grants actions/checks/contents/id-token/pull-requests, but no statuses permission. Line497 selects github.token as SCHEDULER_READ_TOKEN for this same-repository PR event. The runner's effective permission list likewise omits Statuses. The endpoint requires Commit statuses read per GitHub's endpoint contract.
This is a status-read permission mismatch in the workflow/consumer call chain, distinct from #1212's cross-repository status publication and from #2116's HWPX policy parsing. No token values are included. Current direct CodeQL success is not scheduler success or merge authorization.
Owner action and acceptance
Owner: central scheduler workflow and consumer permission contract. Inspect all caller permission ceilings and the current scheduler writer; prepare the minimal job-scoped status-read contract correction, with no status-write or organization/App grant expansion. Do not treat 403 as empty/successful statuses. Verify an existing permitted read credential alternative only if its declared authority matches the target; no credential bypass.
Add/extend the canonical workflow permission regression, validate same-repo and cross-repo token selection, and obtain actual hosted exact-head combined-status read evidence after authorized integration. Keep missing checks, review and substantive research findings fail closed. No workflow permission has been changed, rerun dispatched, or merge bypass used in this investigation.
Internal investigation/coordination deadline and next review: 2026-09-13 (current required scheduler failure merits next-day action); earlier on owner change. Completion requires loaded workflow SHA and consumer permission validation plus successful endpoint/read behavior, not issue creation. Source was retrieved read-only through GraphQL; gh run view --log-failed hit workflow404, but the direct job-log endpoint succeeded. A subsequent REST source lookup was rate-limited; that tooling limitation is separate from the hosted integration403.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
seonghobae commentedon Sep 12, 2026
Taking the minimal
scan-pr-queue.permissions.statusescorrection and its existing workflow-contract regression on branchfix/scheduler-status-read-2120, based on protected mainfb17ef556f94f673234aa557254ae52779e9a7b0(2026-09-12). Existing scheduler PRs were checked: #2003 owns mutation-token proof, #2002 Actions credential routing, and #1231 preserves their historical combined delta; this change does not alter those token-selection or mutation paths. No existing PR specifically implementing the status-read permission was found.The canonical same-repository read token resolves to
github.token, whilescan-pr-queue.permissionsomits statuses. The combined-status endpoint requires Commit statuses read. Plan: add only job-scopedstatuses: read, assert the effective job block in the existing token contract test, retain cross-repository token selection and fail-closed API errors. Consumer.githubis absent at the inspected PR head, so a repository-local reusable caller has not been established; required-workflow run provenance still needs validation rather than guessing a caller filename.Project #1: In Progress. Acceptance remains exact loaded central SHA plus successful hosted status read; local contract tests are not that runtime evidence. No status-write or organization/App installation grant is being added.
Implementation published as #2121 at exact head
1c5c6b7afa841f7a4a999f54d45ef8d504a2d818. RED assertion commit9521b6771failed because the status permission list was empty. GREEN: 452 existing workflow/credential/status tests passed withGITHUB_ACTIONS=true; the changed assertion also passed without that variable. Workflow-only Actionlint and diff whitespace validation passed. Read-only peer review found no grant/credential-scope regression; this is not formal GitHub approval.The current-head hosted workflows are queued, with no review verdict yet. No duplicate dispatch or bypass was requested. Required-check/independent-review and post-integration private consumer status-read evidence remain pending. #2116's separate candidate now passed 3,061 full-repository tests, with one reviewed-LLVM19 host-tool skip; its canonical writer coordination is still pending.
seonghobae commentedon Sep 13, 2026
Additional consumer evidence, same head:
ContextualWisdomLab/late-life-anxiety-reanalysisPR #10 heada1cd5bc6783c6510dfcf937f523c733366e82213, checked 2026-09-13 KST via REST job logs.Both CodeQL shards on the required run
34700410434fail with the same integration-token message before any scan is dispatched:Dispatch current-head CodeQL scan(job103571810868): step "Dispatch current-head CodeQL scan" →gh: Resource not accessible by integration (HTTP 403)while validating live PR state/base identity (envPR_NUMBER=10,PR_BASE_SHA=c8fd9330…).CodeQL compatibility analysis (python)(job103571590442): step "Read current-head CodeQL dispatch verdict" → sameHTTP 403, then "CodeQL scan dispatch or exact-head verdict read did not succeed (outcome=failure)".scan-pr-queue(job103571043736) reproduces the/commits/<sha>/status403 already recorded in this issue.No CodeQL SARIF or verdict exists for this head, so the failure is a permissions/dispatch outcome, not a code-scanning result. If the CodeQL dispatch path reads PR state with a different token than the scheduler status read, it may need a separate fix; recording it here rather than opening a duplicate issue. Consumer-side, no repository change can address this.
seonghobae commentedon Sep 17, 2026
Triage (2026-09-18): close-as-done candidate
Unique delta appears on protected
mainvia merged #2121 (statuses: readon the scheduler scan job). Doctoring:docs/doctoring/scheduler-status-read-permission.md.Ranked backlog: #2251 /
docs/doctoring/issue-backlog-org-impact-20260918.md. Spot-check a same-repo combined-status read on a current private consumer head before closing.seonghobae commentedon Sep 17, 2026
Closing after spot-check: unique valid delta is on protected
main.Merged fix: #2121 (merged 2026-09-13,
0ad785de2055f2edd084268ca9238b0fab551160)Tree evidence on
origin/main:.github/workflows/pr-review-merge-scheduler.ymlscan job declaresstatuses: readdocs/doctoring/scheduler-status-read-permission.mdpins the#2120incident and repairVerified with
git grep/ file presence onorigin/main(not redundancy alone).