[teamleaderleo]

The CLA quota janitor (#25415) re-ran quota-caused CLA failures, but too late. p0-swift-linux reported that from about 12:40Z on 2026-10-26 the CLA policy guard rejected every PR, and #25466 was blocked for 80 minutes.

Root cause (from the run logs)

• The rejects are quota rejects. Each guard reject comes 80 to 200 ms after the regression matrices print, which is the guard's first gh api read (api_json raises PolicyError, and the guard prints only "rejected the proposed policy"). CLA Assistant runs for the same PRs at the same moments logged API rate limit exceeded for installation, for example run 40355511173 at 16:04:27Z next to guard 40355524808 at 16:04:22Z on ci(cmux-next): DEV publish retries a release call the rate limit refused #25517, and 40354478049 next to 40354477800 on ci(rescue): wait through GitHub rate limits instead of leaving a cancelled run un-re-run #25510.
• When the janitor ran, its match worked. At 14:19Z it re-ran guard 40327017232 for ci(cmux-next): re-land Linux DEV signing with the signer executable, and guard script modes #25466 on CLA Assistant evidence. The match was not the problem. The problem was how often it ran:
  • The */10 cron fired at 12:35Z and then not again until 14:19Z (104 min). That gap matches ci(cmux-next): re-land Linux DEV signing with the signer executable, and guard script modes #25466's 80 minutes.
  • At 15:42Z the janitor found the workflow token's core budget at 0 of 5000 (reset at 16:13Z). That reset was more than 15 min away, so the pass exited and did nothing. So this budget was not only a secondary limit. Core was fully spent too.

Change

• ci-cla-quota-rerun.yml now also runs on workflow_run completed of CLA Assistant and CLA policy guard. A job starts only for a pull_request_target run that failed, or for a completed re-run (attempt above 1), so a backlog drains one pass after another. The cron stays as a fallback. No new secrets, no permission changes, and no pull_request_target. The job reads nothing from the triggering run and checks out its own default-branch script. SOURCE_WORKFLOW_PATHS is declared, as test_ci_workflow_run_sources requires.
• Concurrency moves to the job, so the comment-triggered CLA runs (about one a minute, all skipped) never take the pending slot.
• A pass that finds the budget spent now waits up to 40 min for the reset (was 15). Job timeout is 47 min. The App token is minted at job start and lives 60 min.
• New guard evidence that needs no x-ratelimit header, no 403 wording and no CLA Assistant failure: if a PR's files (pulls/N/files, at most 3 pages) touch none of the paths validate-cla-policy.rb reads as policy (CLA_POLICY_PATHS + GUARD_PATHS, renames included), the PR proposes no policy and a failed read is the likely cause. This is a retry heuristic, not proof: a stale event base, or an old policy with no usable test-merge commit, can still be rejected for real. So it is used on attempts 1 and 2 only, and a real reject of that kind stays failed after that. A test keeps POLICY_PATHS equal to the guard's own lists.
• Open PRs are now read most recently updated first (sort=updated). More than 500 are open, and a fresh reject's PR was just updated.

A real policy reject still fails: when a PR changes a policy path, the guard is re-run only on the existing API-failure evidence.

Not changed: the guard's own token

The guard's GH_TOKEN is pinned to ${{ secrets.GITHUB_TOKEN }} by validate-cla-policy.rb (GUARD_VALIDATE_ENV), and the guard workflow's bytes are digest-pinned (EXPECTED_GUARD_WORKFLOW_DIGEST). Moving it to the glaeda-route App budget, as #25408 did for risk tier, would mean exposing the App key to a pull_request_target control-plane workflow. That is a trust-policy change, so this PR does not make it.

Risk

Low and CI-only. A pass reads about 12 calls from the App's own budget and makes only the free rate_limit read of the workflow token. Failure triggers that arrive during a pass collapse into one pending pass. A run that keeps failing for real stops at MAX_GUARD_ATTEMPT / NO_POLICY_MAX_ATTEMPT.

Tests

cmux-ci test (fast-checks run 40357180685): tests/test_cla_quota_rerun.py plus the workflow_run-sources, concurrency, job-scoped-permissions, actionlint-coverage and workflow_run-budget suites gave 88 passed. The one failure, test_ci_failfast_keeps_failure_rollups_and_bounds_observed_tails ("ci.yml has no tests job"), fails the same way on main. check_workflow_concurrency.py and actionlint 1.7.7 on the workflow both pass. On the final head, ci-guards.yml runs tests/test_cla_quota_rerun.py (29 tests OK, and the wiring guard passes).

Review: an independent Codex gpt-6-astra xhigh reviewer gave SHIP on head e775a3f, with no blocking findings. Its one nonblocking note (call the no-policy evidence a heuristic) is addressed.

Agent session: agent session

🤖 Generated with Claude Code

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[teamleaderleo]

Owned by an agent session · session

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Passes: CI passes on e775a3f6b0.

CI passes on e775a3f6b0 (run 40358917457 attempt 1).

Written by scripts/ci/classify_failures.py (ci-failure-attribution.yml); signatures are its SIGNATURES table. A machine verdict is the runner's fault, not this PR's; yours means the failing file is one this PR changes, also red on main that main's latest full suite fails the same way, seen on other PRs that it failed on another pull request's run lately.

CI fast guards passes on e775a3f6b0 (run). This covers only the fast guards, not CI: CI's result is ci-status.

Merge receipt for e775a3f6b0: every check was green at merge (10 verified; 16 skipped by policy). Full suite runs on main after merge.