Skip to content

fix(scheduler): rerun the Strix scan job, not a sibling job - #1586

Merged
seonghobae merged 6 commits into
mainfrom
fix/strix-rerun-select-scan-20260901
Sep 1, 2026
Merged

fix(scheduler): rerun the Strix scan job, not a sibling job#1586
seonghobae merged 6 commits into
mainfrom
fix/strix-rerun-select-scan-20260901

Conversation

@seonghobae

@seonghobae seonghobae commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Root cause

ContextualWisdomLab/bandscope#1055 exact head 9b435f5159e1389e0e122b0a12e1a630fba1950f exposed a real central scheduler defect. Its trusted Strix Security Scan rollup contained both the failed authoritative scan job strix (99212031836) and a skipped sibling publisher publish-manual-pr-evidence-status (99212677006). is_strix_context() is intentionally broad because evidence aggregation must recognize the whole trusted workflow, but dispatch_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 selected 99212677006, hit the separate least-privilege Actions-permission 403, emitted action_error, and left downstream OpenCode without a formal current-head verdict.

Test-first repair

  • RED head dcce9e55306e5049cc363a4c5ba05076b62d8a6a added tests/test_strix_rerun_job_selection.py using the exact BandScope workflow/job identities and requiring rerun target 99212031836 only.
  • Production now adds is_strix_scan_check_run(): concrete rerun selection requires a CheckRun named exactly strix that 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 passes is_strix_scan_check_run to matching_actions_job_id() and can no longer select publish-manual-pr-evidence-status as 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 33495280490 failed 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 run 33495467696 completed 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

  • protected base: main@7f3581693dc0f40df32914c695645f500e3a3ba7
  • exact current head: e7e4a8d44caa2a537490a7a2432330c5ea26cd14
  • final changed files: scripts/ci/pr_review_merge_scheduler.py and tests/test_strix_rerun_job_selection.py only
  • comparison 5b7ddd1e55742c5fca3232c4c6f22258e5f95997...e7e4a8d44caa2a537490a7a2432330c5ea26cd14 is ahead with zero file differences, proving the temporary-workflow add/remove concurrency did not alter the repaired source/test tree
  • predecessor Draft fix(scheduler): rerun the Strix scan job, not a sibling job #1584 was closed only because the connected Ready mutation is broken by a GitHub GraphQL Repository.fullDatabaseId schema mismatch; this non-Draft successor preserves the identical branch/history and requests fresh current-head checks/reviews

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


Devin Review

@coderabbitai

coderabbitai Bot commented Sep 1, 2026

Copy link
Copy Markdown

Warning

Review limit reached

Next included review available in 56 minutes.

Check out review usage here.

View limit details

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

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: f447e66a-e7b0-4d08-ad0e-cb4817e396e3

📥 Commits

Reviewing files that changed from the base of the PR and between c11ff39 and e7e4a8d.

📒 Files selected for processing (2)
  • scripts/ci/pr_review_merge_scheduler.py
  • tests/test_strix_rerun_job_selection.py

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copy link
Copy Markdown
Contributor Author

QUEUE_SATURATION_CHICKEN_EGG on exact head e7e4a8d44caa2a537490a7a2432330c5ea26cd14. The current Ready successor is mechanically mergeable against protected main@c11ff39a30db03118c327cb40ff26d05608050b5, has zero unresolved review threads and no submitted CHANGES_REQUESTED, and CodeRabbit is success. The causal production/test tree was constructed and exercised by hosted one-shot run 33495467696 (focused exact BandScope scan-vs-publisher regression, scheduler self-test, clean diff); the only later tree change was retirement of the already-purpose-complete temporary workflow after a concurrent writer reintroduced it. Current-head protected security/quality lanes have materialized but remain queued in the saturated central Actions fleet, and Devin is pending rather than reporting a substantive finding. This central scheduler repair is itself required to unblock downstream semantic-review recovery. No failing source test, real security finding, malformed provenance, conflict, or meaningful review objection is being bypassed. Merging only with expected-head identity and immediately re-validating BandScope #1055.

@seonghobae
seonghobae enabled auto-merge (squash) September 1, 2026 10:09
@seonghobae
seonghobae merged commit 035269a into main Sep 1, 2026
65 of 106 checks passed
@seonghobae
seonghobae deleted the fix/strix-rerun-select-scan-20260901 branch September 1, 2026 10:09

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Devin Review

Comment on lines +3100 to +3106
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)
)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 Info: Trusted identity remains enforced

is_strix_scan_check_run requires both the authoritative job name and trusted workflow identity. Unrelated same-named checks cannot become rerun targets.

Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

seonghobae pushed a commit that referenced this pull request Sep 7, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant