[ryanduguid]

Summary

Windows CI failed a different test on most recent main runs, each time on a durable-write or retirement deadline. Tests now keep their temporary files on the runner's workspace drive, where durable writes are about 10 to 40 times faster, so they stop using up their budgets. No test budget or production deadline changes.

  cargo test step (Windows and Linux)
+   TEMP, TMP = runner.temp
  atomic_records_and_locks_work_beyond_max_path
-   one 210-character component (about 251 characters from a short temporary root)
+   two 210-character components (past MAX_PATH from any root)

Evidence

• Before: f12ebe9 failed check (windows-latest) on two attempts with different tests, the second with Atomic publication deadline reached. a5ff8be also failed on a different Windows test.
  After: with temporary files on D:, 3 of 3 Windows jobs had no timing failure. Their only failure was the path test fixed here.
• Durable-write probe, 3 runners: median 6.3 to 9.0 ms on C: and 0.22 to 0.56 ms on D:; p99 24 to 27 ms on C: and 0.7 to 1.3 ms on D:.
• Windows test step: 919 to 1118 s, down from 1549 to 2020 s.
• Local, Windows: the path test, cargo clippy --all-targets --locked -- -D warnings and cargo fmt --check pass.

Merge danger

Door: two-way. Blast radius: CI

Windows CI no longer exercises durable writes on the system drive. Local runs still do.

Unverified

• Three clean runs are thin evidence for a flake, so the failure rate needs watching over later runs.
• Production budgets on a system drive are unchanged and not re-tested here. The same deadlines fail closed, and this PC's C: had a 5.4 ms p99 on the probe.
• One Linux failure on a5ff8be (Target disposition deadline reached, a 3 s test deadline) is not addressed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud