flake: cli/sessionstore TestKeyring/OverwriteToken (windows)

[flake-investigator]

CI Run: https://github.com/coder/coder/actions/runs/20134964926
Commit: 8ead6f795d182b747309740b300ddd567f31a225 (author: Danielle Maywood)

Failing job: test-go-pg (windows-2022)
Failure time: 2025-12-11T13:49:21Z (same window as Slack alert)

Test failure:

• Package: cli/sessionstore
• Test: TestKeyring/OverwriteToken
• File: cli/sessionstore/sessionstore_test.go:153
• Error: "Received unexpected error: Element not found."

Log evidence:
...snip...
=== FAIL: cli/sessionstore TestKeyring/OverwriteToken (0.00s)
sessionstore_test.go:153:
Error Trace: C:/actions-runner/coder/coder/cli/sessionstore/sessionstore_test.go:153
Error: Received unexpected error:
Element not found.
Test: TestKeyring/OverwriteToken
--- FAIL: TestKeyring/OverwriteToken (0.00s)
=== FAIL: cli/sessionstore TestKeyring (0.01s)
DONE 1999 tests, 79 skipped, 2 failures in 84.114s
...snip...

Root cause classification: Flaky test (Windows keyring interaction). The subtest writes a token, verifies read, overwrites with a second token, and then read unexpectedly fails with "Element not found." Suggests intermittent Windows Credential Manager read/write inconsistency or race between writes.

Duplicate search summary:

• repo:coder/internal "TestKeyring/OverwriteToken" — no results
• repo:coder/internal sessionstore keyring windows test — no results
• repo:coder/internal "Element not found" sessionstore — no results
  Also checked last 30 days of closed issues; no matching flake.

Assignment analysis:

• Recent test file changes: cli/sessionstore/sessionstore_test.go last modified in feature work adding Windows/macOS keyring support.
  • 2025-11-12 Zach (zedkipp) "feat(cli): add macOS support for session token keyring storage" (5e85663c)
  • 2025-10-30 Zach (zedkipp) "feat(cli): optionally store session token in OS keyring (Windows)" (139dab7c)
    Given ownership of the test and feature, assigning to Zach for triage.

Reproduction: Only observed in CI Windows runner. No stable local repro steps; may require rerunning job on windows-2022 with --use-keyring behavior enabled by tests.

Action requested:

• Investigate Windows Credential Manager usage in sessionstore keyring backend for overwrite path; add retries or ensure API semantics guarantee immediate availability after write.
• Consider isolating per-test service names (already unique) and any cleanup order to avoid collisions.

[zedkipp]

From my initial triage, the only possible scenario I can see is that a parellel test process on the same machine was racing to read/write the same keyring credential. The keyring tests generate a credential key using the test name and a timestamp. This failure would be possible if two parallel test processes running the same test read/write to the keyring at the same timestamp.

The CI build history seems to indicate this is plausible. The logs don't have exact enough timestamps (e.g. when the sessionstore package tests ran) to know definitively. I see the job that flaked and another job ran within a couple minutes of each other: https://github.com/coder/coder/actions/runs/20135073861/job/57789800570 https://github.com/coder/coder/actions/runs/20134964926/job/57786294130.

I'm going to make a PR to better isolate parallel test processes accessing the real OS keyring. While I don't have a smoking gun on this failure, I think it's still a worthwhile robustness change.