codeql-scan-dispatch.yml has never run: env: cannot hold the client_payload matrix array (0 success / 136 failures since #1776)

.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.

codeql-scan-dispatch.yml    success=0     failure=136    last_success=never

Cause

GitHub rejects the workflow at template validation:

The template is not valid. .github/workflows/codeql-scan-dispatch.yml
(Line: 149, Col: 28): A sequence was not expected

Line 149 assigns the dispatched matrix straight into env::

SUPPLIED_MATRIX: ${{ github.event.client_payload.matrix || '' }}

and codeql-pr.yml:257 sends that key as an array:

matrix:[{language:$language,"build-mode":$build_mode}]

An env: value must be a scalar, so the expression yields a sequence and the whole workflow fails to compile. yaml.safe_load parses 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 matches success=0.

Likely fix

Serialise before assignment:

SUPPLIED_MATRIX: ${{ toJSON(github.event.client_payload.matrix) }}

I have not applied this. It needs someone who can exercise a real repository_dispatch end to end, and the consumer of SUPPLIED_MATRIX should 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 languages and both CodeQL 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, since codeql-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_ACTOR fail for a different reason, and I initially assumed one shared cause — they don't share it:

workflow	success	failure	last success	cause
`codeql-scan-dispatch.yml`	0	136	never	invalid template (this issue)
`opencode-review-dispatch.yml`	466	9609	2026-08-26	authorization rejected: actor `opencode-agent[bot]` vs variable `github-actions[bot]`
`pr-review-fix-scheduler.yml`	405	10	2026-08-16	not diagnosed

The opencode-review-dispatch mismatch 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

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=0

Two jobs are created, validate-dispatch receives 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_dispatch after 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-valued client_payload.matrix, the toJSON() 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.

교차 저장소 증거: 실패가 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#77`

Ready/mergeable at unchanged exact head d386d6f57e0c8de3e4839d6c61b593e41f9d7e20 on main@5829a0f08d78de464dd24393ce5d0f25fba9d126. Repository-owned exact-head evidence is otherwise terminal GREEN: CI 33907688502, SAST Semgrep 33907688360, and Security Scan 33907688421 all succeeded. Devin Review and CodeRabbit statuses are also successful; this does not substitute for required deterministic CodeQL evidence.

Required CodeQL PR run 33907688467 failed only in CodeQL compatibility analysis (actions) job 101255548785. The job acquired a real ubuntu-24.04 runner. On run attempt 2 it failed at Request current-head CodeQL scan dispatch with the exact message Exact CodeQL job was rerun without an authenticated terminal verdict. The subsequent enforcement step failed because no authenticated terminal codeql-dispatch/actions verdict existed. No Wardnet test/source failure is present in that run.

`ContextualWisdomLab/wardnet#140`

Ready/mergeable at unchanged exact head 054c11aafe835e497d6149efb09f1ccdee9d03bd on the same protected main. The previously queued repository lanes have now completed: CI 33923492873, Fuzz 33923492809, Security Scan 33923492923, and SAST Semgrep 33923493032 are all terminal SUCCESS. The sole current repository-gate failure is CodeQL PR 33923492956.

Its CodeQL compatibility analysis (actions) job 101218136109 acquired a real Ubuntu 24.04 runner. Attempt 1 successfully validated live Wardnet PR/head metadata, obtained OIDC/app credentials, and POSTed a codeql-scan repository dispatch with exact target/head/run/job identity. It then failed closed with VERDICT_STATE=pending and CodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict. No authenticated codeql-dispatch/actions verdict 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=success produced from the exact repository/head payload. No predecessor/manual/model-only status should transfer.

fix(dispatch): parse the actor allowlist identically in all three con…

Additional exact consumer evidence from Wardnet confirms this remains a live causal CodeQL control-plane defect rather than a Wardnet source failure.

ContextualWisdomLab/wardnet#77 is Ready/mergeable at unchanged exact head d386d6f57e0c8de3e4839d6c61b593e41f9d7e20 against protected main@5829a0f08d78de464dd24393ce5d0f25fba9d126. Exact-head repository CI 33907688502, SAST Semgrep 33907688360, and Security Scan 33907688421 all terminated success. Required CodeQL PR run 33907688467 did not: job 101255548785 failed at Request 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 with Exact CodeQL job was rerun without an authenticated terminal verdict. The follow-up enforcement step then failed with CodeQL scan dispatch or exact-head verdict read did not succeed (outcome=failure). The exact target metadata remained Wardnet PR 77 / head d386d6f... / base 5829a0f...; 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/actions terminal verdict exists and attempt 2 cannot redispatch. GREEN: repair codeql-scan-dispatch.yml so 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.

fix(dispatch): parse the trusted-dispatcher allowlist identically in …

fix(codeql): serialise the dispatched scan matrix with toJSON (#1926)

Status after #1926 merged (13:57Z): 10/10 completed codeql-scan-dispatch runs 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@e9ee8470dbafff1c4518b45df165725bff80117e CodeQL PR run 33962688991 still shows the consumer side correctly dispatching codeql-scan and failing closed with VERDICT_STATE=pending in jobs 101316155183 (python) and 101316155232 (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 as opencode-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@e9ee8470dbafff1c4518b45df165725bff80117e CodeQL PR run 33962688991 acquired real ubuntu-24.04 runners. Detect CodeQL languages job 101297220371 completed success. Both compatibility jobs then reached the central dispatch path: python 101316155183 and actions 101316155232 each completed Request current-head CodeQL scan dispatch successfully and failed only at Release 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: CI 34019585668 SUCCESS, Security Scan 34019585622 SUCCESS, SAST 34019585640 SUCCESS; CodeQL PR 34019585679 detects languages successfully, requests current-head scan dispatch successfully, then CodeQL compatibility analysis (actions) job 101453924276 fails only at Release runner or enforce current-head CodeQL verdict.
ContextualWisdomLab/wardnet#155@fb93b61a4a4da30a3471453051ebfb0ed3f63d34: CI 34020141305 SUCCESS, Fuzz 34020141277 SUCCESS, Security Scan 34020141306 SUCCESS, SAST 34020141279 SUCCESS; CodeQL PR 34020141314 is 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 .github truth, 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@e14e88c530f9acf1f77e3dc8b0a9197bb1d3172b reproduces this exact owner failure mode. Required CodeQL PR run 34038416821 dispatched all three compatibility shards; jobs 101506775164 (python), 101506775186 (actions), and 101506775233 (javascript-typescript) each successfully requested a current-head scan and then failed closed with VERDICT_STATE=pending. For javascript-typescript, the log records successful OIDC/app-token dispatch followed by CodeQL 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.yml execution 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: 34035088827

Same-head repository/security evidence is otherwise terminal GREEN: CI 34035088701, Security Scan 34035088645, SAST 34035088659, Python Security 34035088669, Postgres Smoke 34035088818, JSONL Governance 34035088665, env-guard 34035088635, A2Z 34035088714, legacy A2Z 34035088690.

CodeQL language detection job 101491572430 succeeds, then all three delegated compatibility jobs fail at dispatch/verdict control-plane boundaries:

javascript-typescript 101498143530: Request current-head CodeQL scan dispatch FAILURE; 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 .github repair for #1925 and its dependent dispatch-identity boundary (#1927 as applicable) reaches protected main, 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.

Fresh Wardnet native-CodeQL consumer specimen, 2026-09-07 KST. ContextualWisdomLab/wardnet#140 remains unchanged at exact a904558b79ef392515dff4b501692112ad6beabf. Repository-local/central non-CodeQL evidence is terminal GREEN on that head: CI 34020215925, Fuzz 34020215929, Security Scan 34020215934, SAST Semgrep 34020215953. CodeQL PR 34020215930 is the only failing exact-head lane: language-detect job 101451281315 succeeded; compatibility job 101455735498 successfully completed Request current-head CodeQL scan dispatch, then failed only at Release 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 head a904558...; 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@01d231fde23b82e2ced258d7bfcb4721ed75706d confirms this control-plane defect is still materially blocking a required CodeQL context. Required run 33892586782, Python job 101179592347, attempt 2 fails before a CodeQL verdict with Exact CodeQL job was rerun without an authenticated terminal verdict; the follow-up gate reports CodeQL scan dispatch or exact-head verdict read did not succeed (outcome=failure). The job's own dispatch logic searches the exact head for authenticated codeql-dispatch/python status from opencode-agent, finds none, and refuses to re-dispatch on RUN_ATTEMPT != 1. The exact commit status inventory currently contains CodeRabbit/Devin statuses but no codeql-dispatch/python or codeql-dispatch/actions terminal 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#72 exact head a4522703b05fd08581169759858b15ae7aba25c0에서 Repository Quality 34033670991, Security Scan 34033670986, SAST Semgrep 34033670992는 모두 terminal success이고, 유일한 hosted failure가 CodeQL PR 34033671013입니다.

그 run의 language detection 101487742089은 success입니다. 이후 CodeQL compatibility analysis (actions) job 101493104768은 Request current-head CodeQL scan dispatch에서 failure 후 verdict enforcement도 failure, CodeQL compatibility analysis (python) job 101493104808은 dispatch 요청 자체는 success지만 Release runner or enforce current-head CodeQL verdict에서 failure입니다. 따라서 이 consumer branch의 PostgreSQL source/test RED와 분리되는 중앙 dispatch/verdict control-plane 증거입니다.

GREEN acceptance: .github owner repair 이후 consumer source/no-op commit 없이 동일 a4522703...에서 detected actions와 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@e9ee8470dbafff1c4518b45df165725bff80117e is consistent with this central defect. CodeQL PR run 33962688991 dispatched both python and actions; compatibility job 101316155183 successfully obtained OIDC/App token and POSTed repository_dispatch, then intentionally failed with VERDICT_STATE=pending because 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.

docs(gap-baseline): record the dispatch-actor outage and its fix, the…

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=success returns 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 carry codeql-dispatch/actions / codeql-dispatch/python = SUCCESS statuses with CodeQL compatibility analysis (*) passing after the dispatch wake (e.g. .github#2060@4d718a73d, #2143@7e5b971a4). The template-validation defect at the env: matrix line was removed by the dispatch rewrite series on main: #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.

Navigation Menu

Repository navigation

codeql-scan-dispatch.yml has never run: env: cannot hold the client_payload matrix array (0 success / 136 failures since #1776) #1925

Cause

Likely fix

Why it went unnoticed

Related but distinct

교차 저장소 증거: 실패가 CodeQL 분석이 아니라 디스패치 층에 국한됩니다

같은 층에서 리뷰도 실패합니다

운영상 영향

`ContextualWisdomLab/wardnet#77`

`ContextualWisdomLab/wardnet#140`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

codeql-scan-dispatch.yml has never run: env: cannot hold the client_payload matrix array (0 success / 136 failures since #1776) #1925

Description

Cause

Likely fix

Why it went unnoticed

Related but distinct

Activity

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

교차 저장소 증거: 실패가 CodeQL 분석이 아니라 디스패치 층에 국한됩니다

같은 층에서 리뷰도 실패합니다

운영상 영향

seonghobae commented on Sep 5, 2026

ContextualWisdomLab/wardnet#77

ContextualWisdomLab/wardnet#140

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 6, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`ContextualWisdomLab/wardnet#77`

`ContextualWisdomLab/wardnet#140`