Repository navigation
codeql-scan-dispatch.yml has never run: env: cannot hold the client_payload matrix array (0 success / 136 failures since #1776) #1925
Description
Activity
Correction (mechanism, not conclusion). The original text says the workflow "fails to compile" and "dies before any step executes". That is wrong, and the distinction changes both the fix's scope and how it can be verified. Flagged by peer review, then confirmed directly against run
33948513003:validate-dispatch conclusion=failure runner=1001681451 steps=4 1. Set up job -> success 2. Exchange OpenCode app token for target metadata -> success 3. Bind workflow inputs to live org PR metadata -> FAILURE <- the env: block 4. Complete job -> success CodeQL dispatch scan (${{ matrix.language }}) skipped runner=null steps=0Two jobs are created,
validate-dispatchreceives a real runner, and two of its four steps succeed. A workflow that failed to compile would produce no jobs at all.env:is evaluated when its step starts, so the invalid expression kills that step only.What this changes:
- The entry path is proven working. Step 2 exchanging the app token means authorization and token handling are healthy here. That further separates this from
opencode-review-dispatch.yml, whose failure is an authorization rejection. - The fix is narrower than stated — one
env:value, affecting one step. - The fix is verifiable by re-dispatch. Since the workflow reaches step 3 today, a single
repository_dispatchafter the fix shows immediately whether step 3 passes. The original framing implied everything downstream was unverified.
Everything else in the issue stands:
success=0 / failure=136 / last_success=never, line 149, the array-valuedclient_payload.matrix, thetoJSON()fix, and the fact that run-level status hides it.Still unverified, and worth keeping open when the fix lands: whether CodeQL scanning was reaching this repository by some other path before #1776 introduced this handler. "Broken since it was added" is established; "no CodeQL coverage since then" is not.
- The entry path is proven working. Step 2 exchanging the app token means authorization and token handling are healthy here. That further separates this from
교차 저장소 증거: 실패가 CodeQL 분석이 아니라 디스패치 층에 국한됩니다
contextual-orchestrator의 열린 PR 세 건(#1028, #1031, #1032)에서 같은 실패를 확인했습니다. 실패 스텝이 전부 동일합니다:FAILED: Request current-head CodeQL scan dispatch FAILED: Release runner or enforce current-head CodeQL verdict중요한 건 같은 커밋에서 나머지 CodeQL 작업은 성공한다는 점입니다. CO#1028 head
b99dc7ea의 CodeQL 계열 체크 전수입니다:completed/success Detect CodeQL languages x2 completed/success CodeQL, supply chain, and SBOM x2 completed/success CodeQL x1 completed/failure CodeQL compatibility analysis (python) completed/failure CodeQL compatibility analysis (javascript-typescript) completed/failure CodeQL compatibility analysis (actions) completed/cancelled CodeQL compatibility analysis (python / javascript-typescript / actions)언어 감지도 성공하고, 실제 분석도 성공하고, SBOM도 성공합니다.
CodeQL compatibility analysis (*)만 실패하고, 그것도 디스패치 요청 스텝에서 죽습니다. job은 러너를 정상적으로 받습니다(예:runner=1001682179,steps=4).즉 이 이슈의 증상은 "CodeQL이 안 돈다"가 아니라 **"CodeQL은 도는데 current-head 디스패치 검증 층이 매번 실패한다"**입니다. 필수 context가
CodeQL compatibility analysis (...)쪽에 걸려 있는 저장소에서는 분석이 실제로 성공했는데도 merge가 막힙니다.같은 층에서 리뷰도 실패합니다
같은 PR들에서 리뷰 체크의 실패 스텝은 이렇습니다:
opencode-review : Fail closed without a current-head OpenCode verdict noema-review : Prepare Noema model verdict세 소비자(CodeQL 호환성, OpenCode, Noema)가 서로 다른 워크플로인데 전부 current-head 디스패치/판정 층에서 죽습니다. #1929(디스패치 actor 허용목록이
github-actions[bot]인데 실제 디스패처는opencode-agent[bot])와 이 이슈가 같은 층의 두 증상일 가능성이 있어 보입니다. 단정하지는 않겠습니다 — 이 이슈의 원인은env:가client_payload배열을 담지 못하는 것으로 이미 특정돼 있고, 그건 actor 불일치와 다른 결함입니다. 두 결함이 같은 층에 겹쳐 있다는 것까지가 제가 확인한 범위입니다.운영상 영향
이 세 PR에는 브랜치에서 고칠 것이 없습니다. CO#1028과 CO#1032는 테스트 실패가 하나도 없고 디스패치 층 실패만 있습니다. 그래서 자동 수정 이벤트가 반복 발생해도 브랜치 쪽에서 취할 수 있는 조치가 없고, 무엇을 push하든 같은 자리에서 죽습니다. (CO#1031은 별개로 실제 테스트 결함이 하나 있어서
481911b0으로 고쳤습니다.)측정 시각 2026-09-05 12:0x UTC.
Wardnet adds two current downstream specimens for this exact producer defect.
ContextualWisdomLab/wardnet#77Ready/mergeable at unchanged exact head
d386d6f57e0c8de3e4839d6c61b593e41f9d7e20onmain@5829a0f08d78de464dd24393ce5d0f25fba9d126. Repository-owned exact-head evidence is otherwise terminal GREEN: CI33907688502, SAST Semgrep33907688360, and Security Scan33907688421all succeeded. Devin Review and CodeRabbit statuses are also successful; this does not substitute for required deterministic CodeQL evidence.Required CodeQL PR run
33907688467failed only inCodeQL compatibility analysis (actions)job101255548785. The job acquired a realubuntu-24.04runner. On run attempt 2 it failed atRequest current-head CodeQL scan dispatchwith the exact messageExact CodeQL job was rerun without an authenticated terminal verdict.The subsequent enforcement step failed because no authenticated terminalcodeql-dispatch/actionsverdict existed. No Wardnet test/source failure is present in that run.ContextualWisdomLab/wardnet#140Ready/mergeable at unchanged exact head
054c11aafe835e497d6149efb09f1ccdee9d03bdon the same protected main. The previously queued repository lanes have now completed: CI33923492873, Fuzz33923492809, Security Scan33923492923, and SAST Semgrep33923493032are all terminal SUCCESS. The sole current repository-gate failure is CodeQL PR33923492956.Its
CodeQL compatibility analysis (actions)job101218136109acquired a real Ubuntu 24.04 runner. Attempt 1 successfully validated live Wardnet PR/head metadata, obtained OIDC/app credentials, and POSTed acodeql-scanrepository dispatch with exact target/head/run/job identity. It then failed closed withVERDICT_STATE=pendingandCodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict.No authenticatedcodeql-dispatch/actionsverdict subsequently arrived.These two heads show both required-workflow states around the same absent terminal producer verdict: #140 successfully sends the exact dispatch and waits; #77's later retry still finds no authenticated result. Branch-side reruns or source churn are non-causal.
RED is an unchanged target head with repository CI/security/SAST (and on #140 Fuzz) GREEN while required CodeQL cannot obtain an authenticated current-head dispatch verdict. GREEN is: merge #1926 or a verified successor, complete the separate dispatcher-identity repair tracked by #1927/#1929 as required, then rerun only the failed required CodeQL jobs on the same unchanged Wardnet heads and require terminal authenticated
codeql-dispatch/actions=successproduced from the exact repository/head payload. No predecessor/manual/model-only status should transfer.- added a commit that references this issue
on Sep 5, 2026 Additional exact consumer evidence from Wardnet confirms this remains a live causal CodeQL control-plane defect rather than a Wardnet source failure.
ContextualWisdomLab/wardnet#77is Ready/mergeable at unchanged exact headd386d6f57e0c8de3e4839d6c61b593e41f9d7e20against protectedmain@5829a0f08d78de464dd24393ce5d0f25fba9d126. Exact-head repository CI33907688502, SAST Semgrep33907688360, and Security Scan33907688421all terminated success. Required CodeQL PR run33907688467did not: job101255548785failed atRequest current-head CodeQL scan dispatch.The job log shows this was run attempt 2. Before any new dispatch it queried
codeql-dispatch/actions, found no authenticated terminal verdict, and deterministically exited withExact CodeQL job was rerun without an authenticated terminal verdict.The follow-up enforcement step then failed withCodeQL scan dispatch or exact-head verdict read did not succeed (outcome=failure). The exact target metadata remained Wardnet PR 77 / headd386d6f.../ base5829a0f...; there is no head-movement explanation.This is consistent with #1925: the delegated native scan/verdict path is broken upstream, so rerunning the compatibility job alone cannot synthesize missing CodeQL evidence and correctly fails closed. RED: a valid unchanged consumer head reaches the central CodeQL compatibility job, but no authenticated
codeql-dispatch/actionsterminal verdict exists and attempt 2 cannot redispatch. GREEN: repaircodeql-scan-dispatch.ymlso the dispatched matrix is accepted as serialized JSON, exercise repository_dispatch end-to-end, publish the authenticated exact-head verdict, and then rerun this same Wardnet CodeQL job to terminal success without changing the product head. Do not weaken the required gate or treat the compatibility wrapper as a substitute for the native scan.Status after #1926 merged (13:57Z): 10/10 completed
codeql-scan-dispatchruns now reach the authorization check and are rejected there (actor=opencode-agent[bot]). The template error in this issue is resolved; the step executes. What remains is the identity allowlist — #1927 / #1929. Full run table and the wording note on #1926.Correction after re-reading the live owner issue timeline:
ContextualWisdomLab/quarantine-sandbox-runtime#1@e9ee8470dbafff1c4518b45df165725bff80117eCodeQL PR run33962688991still shows the consumer side correctly dispatchingcodeql-scanand failing closed withVERDICT_STATE=pendingin jobs101316155183(python) and101316155232(actions). However, #1925's matrix/env defect had already been repaired by central PR #1926 before this consumer run; subsequent central dispatch runs reach authorization and are rejected asopencode-agent[bot]against the stale configured actor. Therefore this downstream specimen should no longer be attributed to the old #1925 template defect. The live owner blocker is the dispatch-identity contract tracked in #1927/#1929. Keep the consumer fail-closed; do not add a quarantine-sandbox-runtime leaf shim or treat the dispatch receipt as CodeQL GREEN.Fresh quarantine-sandbox-runtime canary (2026-09-06 KST) is consistent with this central dispatch-layer defect and should not trigger leaf churn.
ContextualWisdomLab/quarantine-sandbox-runtime#1@e9ee8470dbafff1c4518b45df165725bff80117eCodeQL PR run33962688991acquired realubuntu-24.04runners.Detect CodeQL languagesjob101297220371completed success. Both compatibility jobs then reached the central dispatch path: python101316155183and actions101316155232each completedRequest current-head CodeQL scan dispatchsuccessfully and failed only atRelease runner or enforce current-head CodeQL verdict. This is a terminal fail-closed required-context failure after runner acquisition, not a quarantine source/test failure or queue symptom. Preserve the exact leaf head; owner GREEN remains a real current-head dispatched CodeQL verdict after the handler repair, with no predecessor/substitute evidence.Fresh Wardnet consumer evidence — 2026-09-06 KST.
Two unchanged, protected-main-current Wardnet candidates independently converge on the same delegated CodeQL failure while their repository/security lanes are GREEN:
ContextualWisdomLab/wardnet#77@2856babd52b3131845a347c6d005b031b7099986: CI34019585668SUCCESS, Security Scan34019585622SUCCESS, SAST34019585640SUCCESS; CodeQL PR34019585679detects languages successfully, requests current-head scan dispatch successfully, thenCodeQL compatibility analysis (actions)job101453924276fails only atRelease runner or enforce current-head CodeQL verdict.ContextualWisdomLab/wardnet#155@fb93b61a4a4da30a3471453051ebfb0ed3f63d34: CI34020141305SUCCESS, Fuzz34020141277SUCCESS, Security Scan34020141306SUCCESS, SAST34020141279SUCCESS; CodeQL PR34020141314is the only failing lane and is likewise the delegated current-head boundary.
This strengthens the consumer-side acceptance criterion for #1925/#1927: after the dispatch handler and trusted identity/base-staleness repairs reach protected
.githubtruth, these unchanged exact Wardnet heads must acquire a CodeQL verdict bound to the same source SHA without leaf-source mutation or predecessor evidence promotion. If native analysis is already successful elsewhere, the compatibility context must still prove that exact verdict rather than fail solely in dispatch/receipt plumbing.Fresh downstream consumer evidence from
ContextualWisdomLab/life-os#247@e14e88c530f9acf1f77e3dc8b0a9197bb1d3172breproduces this exact owner failure mode. Required CodeQL PR run34038416821dispatched all three compatibility shards; jobs101506775164(python),101506775186(actions), and101506775233(javascript-typescript) each successfully requested a current-head scan and then failed closed withVERDICT_STATE=pending. For javascript-typescript, the log records successful OIDC/app-token dispatch followed byCodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict.No authenticated terminal verdict arrived before the required job exited.This is not a LifeOS source finding and must not be converted into a leaf CodeQL bypass or stale success. The consumer remains on the same exact head; owner acceptance remains a valid
codeql-scan-dispatch.ymlexecution that publishes the authenticated exact-head verdict and reruns the matching required job. Please preserve the separate dispatch-identity dependency in #1927 when repairing #1925.Fresh downstream canary from the dependency-owner lane confirms this is still an active central CodeQL control-plane blocker, not a leaf source failure.
Consumer:
ContextualWisdomLab/xtrmLLMBatchPython#219
Exact head:e3464761d0970c51d3cae14ac1e18f8c6f8c61b8
CodeQL PR run:34035088827Same-head repository/security evidence is otherwise terminal GREEN: CI
34035088701, Security Scan34035088645, SAST34035088659, Python Security34035088669, Postgres Smoke34035088818, JSONL Governance34035088665, env-guard34035088635, A2Z34035088714, legacy A2Z34035088690.CodeQL language detection job
101491572430succeeds, then all three delegated compatibility jobs fail at dispatch/verdict control-plane boundaries:- javascript-typescript
101498143530:Request current-head CodeQL scan dispatchFAILURE; terminal verdict enforcement FAILURE; - python
101498143610: same; - actions
101498143671: same.
The consumer has no reason to mutate source or create a source-neutral re-kick. GREEN acceptance for this canary: after the canonical
.githubrepair for #1925 and its dependent dispatch-identity boundary (#1927 as applicable) reaches protectedmain, the unchanged consumer SHA above must obtain a real terminal native CodeQL verdict for every detected language, without synthetic statuses, consumer-local workflow forks, skipped/neutral promotion, or gate weakening. Keep the dependency/security lane itself distinct: its fresh Security Scan is already GREEN on the exact SHA.- javascript-typescript
Fresh Wardnet native-CodeQL consumer specimen, 2026-09-07 KST.
ContextualWisdomLab/wardnet#140remains unchanged at exacta904558b79ef392515dff4b501692112ad6beabf. Repository-local/central non-CodeQL evidence is terminal GREEN on that head: CI34020215925, Fuzz34020215929, Security Scan34020215934, SAST Semgrep34020215953. CodeQL PR34020215930is the only failing exact-head lane: language-detect job101451281315succeeded; compatibility job101455735498successfully completedRequest current-head CodeQL scan dispatch, then failed only atRelease runner or enforce current-head CodeQL verdict. This unchanged consumer head is therefore a clean acceptance canary for #1925. After the dispatched-handler template repair, require the native handler to materialize and execute for exact Wardnet heada904558...;pending, absent, skipped, synthetic or predecessor verdicts remain non-passing. Preserve all exact-head binding and do not ask Wardnet to source-churn or weaken CodeQL.Fresh downstream evidence from
ContextualWisdomLab/pg-llm-batch#233@01d231fde23b82e2ced258d7bfcb4721ed75706dconfirms this control-plane defect is still materially blocking a required CodeQL context. Required run33892586782, Python job101179592347, attempt 2 fails before a CodeQL verdict withExact CodeQL job was rerun without an authenticated terminal verdict; the follow-up gate reportsCodeQL scan dispatch or exact-head verdict read did not succeed (outcome=failure). The job's own dispatch logic searches the exact head for authenticatedcodeql-dispatch/pythonstatus fromopencode-agent, finds none, and refuses to re-dispatch onRUN_ATTEMPT != 1. The exact commit status inventory currently contains CodeRabbit/Devin statuses but nocodeql-dispatch/pythonorcodeql-dispatch/actionsterminal verdict. This is therefore not a CodeQL finding in pg-llm-batch source and should not be repaired by weakening/retriggering the leaf required check. #1927 remains the next authorization prerequisite once the handler reaches its script. Please use #233 as an unchanged downstream acceptance head when the central handler is repaired: native dispatch must publish authenticated terminal verdicts for both Python and Actions, then the required CodeQL compatibility jobs must become terminal success without leaf-source churn.추가 consumer canary를 남깁니다.
mhtml-etl-gateway#72exact heada4522703b05fd08581169759858b15ae7aba25c0에서 Repository Quality34033670991, Security Scan34033670986, SAST Semgrep34033670992는 모두 terminal success이고, 유일한 hosted failure가 CodeQL PR34033671013입니다.그 run의 language detection
101487742089은 success입니다. 이후CodeQL compatibility analysis (actions)job101493104768은Request current-head CodeQL scan dispatch에서 failure 후 verdict enforcement도 failure,CodeQL compatibility analysis (python)job101493104808은 dispatch 요청 자체는 success지만Release runner or enforce current-head CodeQL verdict에서 failure입니다. 따라서 이 consumer branch의 PostgreSQL source/test RED와 분리되는 중앙 dispatch/verdict control-plane 증거입니다.GREEN acceptance:
.githubowner repair 이후 consumer source/no-op commit 없이 동일a4522703...에서 detectedactions와python모두 실제 current-head CodeQL terminal verdict를 받아 CodeQL PR context가 success가 되어야 합니다. mhtml-etl-gateway 쪽 workflow fork, synthetic status, gate bypass, scanner suppression으로 대체하지 않습니다.Fresh consumer evidence from
ContextualWisdomLab/quarantine-sandbox-runtime#1@e9ee8470dbafff1c4518b45df165725bff80117eis consistent with this central defect. CodeQL PR run33962688991dispatched bothpythonandactions; compatibility job101316155183successfully obtained OIDC/App token and POSTedrepository_dispatch, then intentionally failed withVERDICT_STATE=pendingbecause no authenticated current-head terminal verdict existed. The leaf repo therefore has no CodeQL source finding to repair. Current root head has since moved for an unrelated native-CI fixture repair, so this predecessor evidence is historical/causal only. Please keep #1925 + #1927 as the central source/authorization owners; quarantine-sandbox-runtime will not add a local CodeQL bypass or substitute scanner.- added a commit that references this issue
on Sep 7, 2026 Closing on re-verification, 2026-09-13: the premise ("has never completed successfully") no longer holds.
GET /actions/workflows/codeql-scan-dispatch.yml/runs?status=successreturns a full page of 23 successful runs, earliest on this page 2026-09-07 00:22Z and latest 2026-09-12 18:00Z, and today's PR heads carrycodeql-dispatch/actions/codeql-dispatch/python= SUCCESS statuses withCodeQL compatibility analysis (*)passing after the dispatch wake (e.g..github#2060@4d718a73d,#2143@7e5b971a4). The template-validation defect at theenv:matrix line was removed by the dispatch rewrite series onmain: #1865 (dcd35b765), #1888 (0eb41a365), #2008 (dd7ea8133), #2009 (78a4937c6), #2028 (7fd571dbc). Remaining dispatch-path work (wake credentials, status publication proofs) continues in #1929 / #2141 and the open #2040/#2051/#2106 stack; those are not the "never runs" defect this issue recorded.
.github/workflows/codeql-scan-dispatch.yml— the handler that runs the actual native CodeQL scan — has never completed successfully. Every run dies before any step executes.Cause
GitHub rejects the workflow at template validation:
Line 149 assigns the dispatched matrix straight into
env::and
codeql-pr.yml:257sends that key as an array:An
env:value must be a scalar, so the expression yields a sequence and the whole workflow fails to compile.yaml.safe_loadparses the file fine locally — this is an Actions template rule, not YAML syntax, which is why it isn't caught by any local lint.Introduced by
c594efad feat(codeql): add the native CodeQL scan dispatch handler (#1776); broken from that commit onward, which matchessuccess=0.Likely fix
Serialise before assignment:
I have not applied this. It needs someone who can exercise a real
repository_dispatchend to end, and the consumer ofSUPPLIED_MATRIXshould be checked for whether it expects the JSON text or the previous (never-working) shape.Why it went unnoticed
The failure is invisible from run-level status.
codeql-pr.yml's own jobs are green — sampled 15 recent successful runs,Detect CodeQL languagesand bothCodeQL compatibility analysis (actions|python)succeeded 15/15 — so the required contexts report healthy while the dispatched scan never happens. Worth confirming what CodeQL coverage actually exists today, sincecodeql-pr.yml's own header describes itself as detecting languages and delegating the real scan to this handler.Related but distinct
The other two workflows gated by
vars.OPENCODE_REPOSITORY_DISPATCH_ACTORfail for a different reason, and I initially assumed one shared cause — they don't share it:codeql-scan-dispatch.ymlopencode-review-dispatch.ymlopencode-agent[bot]vs variablegithub-actions[bot]pr-review-fix-scheduler.ymlThe
opencode-review-dispatchmismatch is filed separately — it is an authorization allowlist, and the correct direction of the fix (update the variable vs. correct the dispatching identity) is a decision for whoever owns that boundary, not something to widen automatically.🤖 Generated with Claude Code