[ci-scan] windows-arm64 checked consistently canceled across jitstress/jitstressregs/gcstress pipelines

[github-actions]

Reasoning

The windows-arm64 checked job is consistently canceled (not failed) across multiple JIT/GC stress outer-loop pipelines on main. In every case, all setup tasks (Initialize job, checkout, CodeQL) complete successfully, but the job is then canceled before it can build or send tests. No build error or test failure is recorded — the cancellation appears to be externally triggered, either by a pipeline-level timeout or by the AzDO agent pool running out of available arm64 agents.

This has been observed across 4 separate pipeline definitions over multiple days, indicating this is not a one-off flake but a systematic infrastructure gap for windows-arm64 in these stress pipelines.

Impact on platforms

Pipeline	Definition	Build ID	Build Date	Result
runtime-coreclr jitstress	109	1408383	2026-05-05	windows-arm64 checked canceled
runtime-coreclr jitstressregs	111	1406635	2026-05-03	windows-arm64 checked canceled
runtime-coreclr jitstress2-jitstressregs	112	1406540	2026-05-03	windows-arm64 checked canceled
runtime-coreclr jitstress-isas-arm	116	1406275	2026-05-02	windows-arm64 checked canceled

Additional evidence: pipeline 112 shows this cancellation in build 1386096 (2026-04-19) as well, confirming this has been happening for weeks.

Errors log

No test or build error — the job is canceled at the AzDO level before any work runs. Example timeline (pipeline 112, build 1406540):

Task: Initialize job          → succeeded
Task: Checkout                → succeeded
Task: Send tests to Helix     → (never started; job canceled externally)
Task: Finalize Job            → succeeded
Job result: canceled

First build it occurred

Earliest observed in this scan window: build 1386096, finished 2026-04-19T18:56:27Z (pipeline 112). Scanned window only. Observed in 4 pipelines across the current scan (5 builds total).

Recommended action

1. Infrastructure investigation: Determine why windows-arm64 agents in the JIT/GC stress pipeline queues are not running the job. Possible causes:
   • The pipeline's arm64 job depends on a Helix queue or AzDO pool that lacks available arm64 agents.
   • A pipeline-level timeout is canceling the job before the arm64 agent can be acquired.
   • The pipeline YAML conditionally skips arm64 builds but the skip result is reported as canceled rather than skipped.
2. Check pool: Verify that the Windows.11.Amd64.Open (or equivalent) Helix queue has live arm64 agents for these pipelines. Check https://helix.dot.net/ for queue health.
3. Owner: @dotnet/dnceng for AzDO pool / Helix queue agent availability on windows-arm64.
4. Related: If the cancellation is intentional (arm64 not yet enabled for these stress configs), update the pipeline YAML to set the job condition: false so it shows as skipped rather than canceled, which currently marks the entire pipeline as failed.
5. Files: .azure-pipelines/coreclr/templates/ (jitstress/jitstressregs/gcstress pipeline YAML definitions).

Note

🔒 Integrity filter blocked 4 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125371 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #125825 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #55803 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #127128 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 19.3M · ◷

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.