[thefinder808]

What happened

CI wedged again this morning on #27 (run 30877370518) — the Test step ran past 15 minutes and the job timeout cancelled it.

Rerunning the identical commit passed in 21 seconds:

Attempt	Tree	Test step
First	654f0f6	wedged >15 min, cancelled
Rerun	654f0f6	21 s, green

So the tree isn't the cause. This is the same intermittent hang that ran through July.

Why it keeps going undiagnosed

Each occurrence destroys its own evidence:

• dotnet test folds restore → build → run into one step, so the wedged phase is unknowable from outside.
• --blame-hang only watches test execution. A wedge in restore or build writes no dump and names no test — which matches exactly what we saw: 8+ minutes elapsed, past the hang threshold, no dump artifact produced.
• The job-level timeout cancels the run, and GitHub retains no logs for a cancelled run. Both gh run view --log and the artifacts endpoint came back empty.

That's three independent reasons a hang leaves nothing behind, which is why July's hangs were never root-caused either.

What this changes

Splits restore/build/test into separate steps with individual budgets, sized so a step timeout fires before the job timeout:

Restore  5m
Build    5m
Test     8m   (blame-hang 4m, so the dump lands inside the budget)
         --
         18m  <  job 20m

The ordering is the point: a step timeout fails that step and lets the job finish, so logs are retained. A job timeout cancels the run and the logs are gone. Next hang will name its phase in the UI even if nothing else survives.

Normal total is ~40 s, so the budgets are loose enough that only a real wedge trips them.

What this does not do

It does not fix the hang. No root cause is proven, and I'd rather say so than ship a guess. What I could rule out:

• Every poll loop in the UI tests (MainWindowFlowTests, SigningRefreshTests, RenderHarness) is time-bounded — fixed Pump durations and a 15 s packaging deadline. None can spin forever.
• Both process calls (ProcessRunner.cs:44, UpdateService.cs:471) use WaitForExitAsync(ct) with a cancellation token.

That leaves restore/build — the phase nothing currently observes. Hence instrumenting rather than patching.

Deliberately not caching ~/.nuget/packages in this PR: restore is the leading suspect, and a warm cache would mask the very phase we're trying to observe. Worth adding once a hang has been caught in a named step.

Verified

• dotnet restore → build --no-restore → test --no-build chain runs clean locally; 136/136 tests pass.
• YAML parses; step budgets sum to 18 ≤ job 20, so steps fail before the job is cancelled.
• No ${{ }} interpolation added (and grep -rn '\${{ *}}' over .github/workflows is clean — an empty expression anywhere, even a comment, fails the whole file).

🤖 Generated with Claude Code