fix(scheduler): rerun the Strix scan job, not a sibling job - #1586
Conversation
|
Warning Review limit reachedNext included review available in 56 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
| def is_strix_scan_check_run(node: dict[str, Any]) -> bool: | ||
| """Return whether a check run is the authoritative Strix scan job.""" | ||
| return ( | ||
| node.get("__typename") == "CheckRun" | ||
| and node.get("name") == "strix" | ||
| and is_strix_context(node) | ||
| ) |
GitHub documents concurrency.queue, but actionlint 1.7.12 rejects a minimal queue: max workflow with unexpected key "queue" (exit 1), so the documented syntax cannot pass the governed validator today. Verified the cause at the source rather than inferring it from the error string: actionlint v1.7.12's Concurrency struct in ast.go models only Group and CancelInProgress, with no queue field, so the key is unknown to it by construction. The entry says so explicitly and attributes the observed error text and exit code to the reproduction reported on #1913, because actionlint is not installed in this container and I did not run it. The entry states that this is validator-schema lag rather than evidence against the feature, and that it is not permission to suppress, downgrade or exempt actionlint. queue: max stays available to a lossless release/deploy/migration lane only once the canonical toolchain can validate it, and only with target locking plus protected head/tag/version/digest verification and idempotency. Toolchain ownership is #1231; naruon#1586 owns release/deploy ordering and did not push the rejected key. Guidance only, no workflow change. Gate: 2975 passed, 1 skipped, 21 subtests, coverage 100%, interrogate 100%. Refs #1231, #1586. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BV96rXhqoR3tYZ9AeAVur4
Root cause
ContextualWisdomLab/bandscope#1055exact head9b435f5159e1389e0e122b0a12e1a630fba1950fexposed a real central scheduler defect. Its trusted Strix Security Scan rollup contained both the failed authoritative scan jobstrix(99212031836) and a skipped sibling publisherpublish-manual-pr-evidence-status(99212677006).is_strix_context()is intentionally broad because evidence aggregation must recognize the whole trusted workflow, butdispatch_strix_evidence()reused that broad predicate to choose one concrete Actions job for rerun. Depending on rollup order it could therefore rerun the publisher instead of the scan; the observed scheduler attempt selected99212677006, hit the separate least-privilege Actions-permission 403, emittedaction_error, and left downstream OpenCode without a formal current-head verdict.Test-first repair
dcce9e55306e5049cc363a4c5ba05076b62d8a6aaddedtests/test_strix_rerun_job_selection.pyusing the exact BandScope workflow/job identities and requiring rerun target99212031836only.is_strix_scan_check_run(): concrete rerun selection requires aCheckRunnamed exactlystrixthat also satisfies the existing broad trusted-workflow predicate.is_strix_context()itself is unchanged, so evidence aggregation still recognizes sibling Strix workflow jobs/statuses.dispatch_strix_evidence()now passesis_strix_scan_check_runtomatching_actions_job_id()and can no longer selectpublish-manual-pr-evidence-statusas the rerun job.Repair-workflow RCA and retirement
A temporary source-fix workflow was used only to apply the already-proven focused repair when the connected surface could not conveniently patch the large scheduler file. Its first run
33495280490failed before commit at/usr/bin/python3: No module named pytest; that was a repair-workflow environment defect, not selector evidence. The workflow was corrected and run33495467696completed terminal SUCCESS, exercising the exact scan-vs-publisher selector contract, scheduler--self-test, and clean-diff checks before producing the production commit and deleting itself.A concurrent writer subsequently reintroduced a stale copy of that one-shot workflow after production already contained the new helper. The stale workflow still searched for the removed old selector line, so it was no longer a valid repair path. It has been removed again on the current branch. The final PR diff contains only the production scheduler change and the regression test; no source-fix/self-modifying workflow remains.
Current exact authority
main@7f3581693dc0f40df32914c695645f500e3a3ba7e7e4a8d44caa2a537490a7a2432330c5ea26cd14scripts/ci/pr_review_merge_scheduler.pyandtests/test_strix_rerun_job_selection.pyonly5b7ddd1e55742c5fca3232c4c6f22258e5f95997...e7e4a8d44caa2a537490a7a2432330c5ea26cd14isaheadwith zero file differences, proving the temporary-workflow add/remove concurrency did not alter the repaired source/test treeRepository.fullDatabaseIdschema mismatch; this non-Draft successor preserves the identical branch/history and requests fresh current-head checks/reviewsNo predecessor, queued, pending, cancelled, skipped, action-required, status-only, or model-only evidence is treated as current-head success. Merge only through ordinary live protection after the unchanged current head satisfies applicable exact-head checks and any fresh substantive review finding is resolved. No force push, self-approval, gate weakening, or bypass is requested.