Yep :( It intentionally tests highly concurrent access with real file system, since on Windows it is weird. The chance of it failing depends on these parameters: https://github.com/luci/luci-go/blob/master/common/auth/internal/proc_cache_test.go#L88

We can either tweak them to reduce the probability of failure, or disable the test. Mocking file system or making it deterministic defeats the purpose of the test.

Would a rename/retry loop work, like we do in other contexts?

This test _tests_ rename/retry loop (see https://github.com/luci/luci-go/blob/master/common/auth/internal/disk_cache.go#L180). Turns out it craps out a lot on Windows under contention. That's the primary reason this test exists: to verify stuff still works even in presence of Windows weird errors.

o lol

Could we make it so that transient errors after retry return nil?
https://github.com/luci/luci-go/blob/master/common/auth/internal/disk_cache.go#L214

if errors.IsTransient(err) {
  return nil
}
return err

---

Alternatively, we could move this logic into the unit test and have it not fail on transient.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot