[Sunrisepeak]

Release 0.23.0's run (43361417784) failed its darwin-arm64 stability check twice, on different fixtures (multi-root, module-faults), for one cause: at a cold start clangd builds several files' prerequisites at once, and the module cache's lock anchor sometimes cannot be opened (Failed to open lock file anchor <cache>/.locks/<hash>: No such file or directory). The file then has no modules for the session — no definition or hover across an import — until it is edited.

How often. Counted over the stability evidence of every round, not only failed ones: 0 of 81 rounds on 0.22.0 (engine -mcppls.10), 1 and 2 of 81 on this release (-mcppls.12); PR 88's darwin conformance met it once more. Same runner image (macos-15-arm64 20261103.629) and the same engine toolchain in both. The engine's code is 0.0.20's, recorded there as known; the larger image (clangd's refactorings, #89) shifted the timing. Nothing in the server touches .locks.

Change. transient_module_failure() (beside failure_kind) names this failure: no unit failed, only the engine's lock. handle_module_failure_ no longer records it — no unplaced failure (whose words an ast_file_not_found would repeat), no stand-in, no doomed closure — and asks clangd to build the importer again 500 ms later, a didChange with no content change, wantDiagnostics and clangd's forceRebuild, which rebuilds the preamble and its prerequisites without closing the file. At most three times per file until the sources change; a lock that keeps failing is then reported as any failure is. Retries are cleared at a clangd start.

Tests. Unit: the parse and classification of the line as CI printed it; an engine with the building fake process: one rebuild per failure after the delay, none at once, nothing reported as unplaced, three at most, reported after. mcpp test: 628 cases pass. The race itself is not reproducible on demand; the release's darwin stability check is where it shows.

Follow-up (engine): the race in the lock anchor's creation; the engine's release promoting the image its PR's candidate tested instead of rebuilding it (v0.0.23's archive differs in bytes from the candidate b00e6559… though the source differs only in CHANGELOG.md).