[Build] main CI fails ~80% of runs: 90-minute job timeouts and missing ARM64 PCHs

Summary

main's CI has been failing most of the time for the past week — 16 of the last 20 runs. The failures look like infrastructure rather than code: the same commit both passes and fails, and the two recurring signatures (a 90-minute job timeout, and missing ARM64 precompiled headers across unrelated projects) are not tied to what changed.

I'm reporting this from the outside rather than proposing a fix, since I don't know the agent setup. Happy to be told it's already known and tracked elsewhere — I couldn't find an open issue for it.

The same commit passes and fails

This is the part that rules out a code cause:

Commit	Failed run	Succeeded run
8e832ee7	388732 (30.9 min)	388719 (53.4 min)
71340eed	388644 (33.5 min)	388617 (59.6 min)
7dd034ff	388535 (32.4 min)	388510 (60.4 min)

All three failures are the ARM64 PCH signature below.

Signature 1 — 90-minute job timeout (8 of 16 failures)

The job running on agent SHINE-OSS-L 5 ran longer than the maximum time of 90 minutes.

Durations tell the story. Successful runs cluster at 53–61 minutes; the timeouts are runs of the same work that drift past the cap:

Result	Durations (min)
succeeded	53.4, 58.2, 59.6, 60.4
timed out	91.1, 91.4, 91.9, 91.9, 92.6, 93.5, 93.9, 97.4

Build IDs: 388558, 388599, 388687, 388708, 388716, 388751, 388875, 388936.

A healthy run finishing at ~60 minutes against a 90-minute ceiling leaves only ~50% headroom, so ordinary variance in agent speed is enough to tip a run over. This looks less like "something got slow" and more like the cap being too close to the normal runtime.

Signature 2 — missing ARM64 precompiled headers (5 of 16 failures)

src\modules\FileLocksmith\FileLocksmithCLI\tests\FileLocksmithCLITests.cpp(1,10): error C1083: Cannot open precompiled header file: 'ARM64\Release\FileLocksmithCLI.UnitTests.pch': No such file or directory

It hits several unrelated projects in the same run — FileLocksmith, AltWindowCycle, Runner — and always fails fast (~30–35 min). Several unrelated projects losing their PCH simultaneously suggests build ordering/parallelism or agent workspace state rather than any one project's configuration.

Build IDs: 388535, 388644, 388732, 388804, 388881.

Why this is worth fixing beyond the noise

For maintainers a flaky pipeline is cheap — re-queue and move on. For PRs from forks it isn't, because the pipeline needs an authorized user to comment /azp run before it will start at all. That gating is the right call for untrusted code, but it means an external contributor cannot re-run anything themselves: every retry costs a maintainer's attention.

Concretely, I asked for /azp run three times in this repo over the past week (#50352, #49276). One of those runs came back red for a Command Palette throughput test unrelated to the PR's changed files, so that request — and the maintainer's time spent on it — bought no signal at all. With main itself red, there's also no green baseline to compare a PR against, so "is this me or is this the pipeline?" takes a build-log dig every time.

Questions

1. Is the 90-minute cap deliberate, or has the build simply grown into it? Raising it, or splitting the x64/ARM64 legs further, would remove most of these failures outright.
2. Is the ARM64 PCH failure known? Happy to open a separate issue for it if these are better tracked apart.

Data gathered 2026-09-16 from the public build history of the PowerToys CI pipeline on refs/heads/main (builds 388510–388936).

Start with PowerToys CI builds 388510–388936 on agent SHINE-OSS-L, comparing the 90-minute timeout runs with successful runs and the ARM64 PCH failures. Use the listed FileLocksmith, AltWindowCycle, and Runner error paths to trace the build behavior; done means identifying the separate causes and documenting actionable fixes or separate follow-up issues.