Repository navigation
[Bug]: desktop-compatibility-trust real CurrentUser Root inspection can return unknown on a loaded Windows runner #7569
Description
Client or integration
Other
Area
Platform (Windows / macOS / Linux)
Summary
tests/clients/desktop-compatibility-trust.test.ts › exact Windows compatibility certificate trust > real CurrentUser Root inspection remains read-only for an unregistered synthetic CA failed once on a Windows runner. It expected "not-trusted" and got "unknown" after about 10 s. That looks like the real CurrentUser Root store inspection hitting its time limit and reporting unknown, not a trust-state regression. Rerunning the same shard at the same head passed, so the case depends on runner timing.
Reproduction
Intermittent. Seen in Cross-platform CI lane=all run 39848076205, attempt 1, job windows 7/9, at head 623ecd4c4c (PR #7552, which changes only three unrelated test files). Attempt 2 of the same job passed.
Version
dev 516aaaa + #7552 (test-only)
Operating system
windows-latest (GitHub Actions)
Provider and model
No response
Logs or error output
error: expect(received).toBe(expected)
Expected: "not-trusted"
Received: "unknown"
at tests\clients\desktop-compatibility-trust.test.ts:78:94
(fail) exact Windows compatibility certificate trust > real CurrentUser Root inspection remains read-only for an unregistered synthetic CA [10044.01ms]
Screenshots and supporting files
No response
Redacted configuration
No response
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
Ingwannu commentedon Oct 23, 2026
Tracking the existing focused fix in #7598, which explicitly references #7569. I checked the patch's approach: cold process startup moves to bounded fixture setup, while the measured product deadline and failure semantics remain unchanged. The certificate-runner seam also has a deterministic deadline-error control; a partial
not-trustedstdout after a killed child must still yieldunknown.This is not yet an integration/release claim, and a warm fixture alone would not prove real cold-start service behavior. Current-head hosted CI/native evidence and unchanged negative controls remain required. Keeping this issue open until the corresponding fix is integrated and its scope is verified; no timeout enlargement or live trust-store mutation was performed here.
test: keep cold first-exec and PowerShell start out of two timed cases (
lidge-jun commentedon Oct 24, 2026
Fixed on dev by #7598 (bd5c2ea): the real CurrentUser Root inspection is replayed once before the timed case, the 10s product deadline is unchanged, and a new seam test drives a deadline breach to unknown on every platform. Please reopen if it recurs.