Repository navigation
Windows supervisor job: credential cleanup left an entry; ordered.exe stayed locked (flakes on #443) #446
Description
Two different Windows failures hit Windows supervisor behavior on #443, whose change (Coven CLI discovery in coven_runtime.rs) reaches neither. The third run of the same commit passed. #444's run of this job, earlier the same day, also passed.
1. Native credential cleanup reported success but left an entry
Job 115509182385, step Run corepack pnpm test:native-e2e:
test windows_cleanup::native_cleanup_is_exact_single_use_bound_and_preserves_unrelated_credentials ... FAILED
panicked at tests\phase1_native_rpc.rs:1369:13:
assertion failed: !entry_present(&service, &account)
rpc.cleanup(&grant)["ok"] was true (asserted just above), but one of installation-id-v1, cave-client-v1:…0001 or cave-client-v1:…0002 was still in Credential Manager. The assertion doesn't say which account. Each run uses its own random service name, so a collision with parallel tests is unlikely.
A cleanup that reports success while leaving a credential behind is worth understanding, even as a flake. A cheap first step is to name the account in the assertion message (tests/phase1_native_rpc.rs isn't lock-pinned), so the next occurrence says which entry survived.
2. A test executable stayed locked
Job 115518915539 (the re-run), step Run real Windows supervisor behavior:
Error: EPERM, Permission denied: \\?\D:\a\chat\chat\test-results\windows-supervisor\<uuid>\ordered.exe
A per-run supervisor test binary couldn't be removed or replaced, which suggests a process still held it, or Defender was scanning it.
Status
Not blocking: the third run passed and #443 merged. This issue keeps the record. Reopen or add evidence if either shows up again.
Activity
BunsDev commentedon Oct 14, 2026
Root causes from the raw logs, with the hardening in #460.
Credential entry survived a successful cleanup. The RPC side re-reads every account after deleting it, under the mutation lock, before answering
ok, so the RPC process saw the entry gone and the test process read it back afterwards. That is the cross-process lost-update behaviour of Windows Credential Manager documented in windows-native-keyring-store #20: "a credential can survive aCredDeleteWthat returned success", measured at 51–99 of 400 credentials across 10 processes and none single-threaded. Our e2e binary ran twelve tests in parallel, each with its own RPC child process. #460 runstest:native-e2ewith--test-threads=1and names the surviving account in the assertion. The upstream fix (#21, a per-user named mutex) is not in the pinned 1.1.0 release; adopting it is a separateCargo.lockrepin.ordered.exeEPERM. The test body had passed; the error came fromcleanupRootremoving anode.execopy a supervised target had just finished running. Windows keeps the image locked until the section is released after the last handle closes, and Defender opens fresh executables.rmSynconly retriesEPERMwhenmaxRetriesis set; #460 sets it.Coven-Harness: Claude Code / claude-fable-5-1
BunsDev commentedon Oct 14, 2026
Follow-up check on the upstream Credential Manager fix, 2026-10-15.
493ecaa, which closed upstream issue Implement the Minimal (macOS) design as a second demo surface #20.v1.1.0(65bf682), andCargo.tomlon its default branch still saysversion = "1.1.0".Chat stays pinned at
=1.1.0withtest:native-e2erunning--test-threads=1(#460). Watching for the first release after 1.1.0. When it lands, the follow-up is: bump the pin insrc-tauri/Cargo.toml, updateCargo.lock, prove it withci:full, then a harness-authority repin PR for the lock-governedCargo.lock. Keep--test-threads=1either way: it costs nothing measurable (the suite takes under a second), and upstream notes the mutex only serializes calls made through the crate, not other software on the runner that calls Credential Manager directly.Coven-Harness: Claude Code / claude-opus-5-5