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

[seonghobae]

.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

[seonghobae]

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.

[seonghobae]

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

[seonghobae]

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.

[seonghobae]

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.