You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NamedLocksTrackingFileManagerTest is flaky on ubuntu-latest #2094
Observed on Verify / ubuntu-latest jdk-21-zulu 4.0.0-rc-6 and, in a separate run, on Verify / ubuntu-latest jdk-25-zulu 4.0.0-rc-6. The excerpt is truncated because the runs were re-run afterwards, which replaced the logs.
Why this looks like flakiness rather than a real failure
The clearest evidence: one of the two branches failed this test, then passed it after a push whose only change was a Javadoc @since tag. A comment-only edit cannot affect file locking, so the same code produced both outcomes.
Beyond that:
Neither pull request touches the named-locks or tracking-file-manager code.
Two different JDKs on the same OS, and green on every other matrix cell.
Both went green on rerun.
Possibly related
#2030 (closed) reported IpcNamedLockFactoryIT as flaky with a timeout, and wondered about thread safety. Different class, but the same area, so it may be worth checking whether a shared cause remains.
I have not reproduced this locally; it did not occur in any local run I made.
Fixed by PR #2098 (f690ba0): the NamedLocksTrackingFileManagerTest lock timeouts were raised from 5s to 30s and FileLockNamedLockFactory.shutdown() is now invoked in AfterEach, eliminating lock leaks between tests. Closing; the further test hardening stays tracked in PR #2102.
Activity
slachiewicz commentedon Aug 31, 2026
Fixed by PR #2098 (f690ba0): the NamedLocksTrackingFileManagerTest lock timeouts were raised from 5s to 30s and FileLockNamedLockFactory.shutdown() is now invoked in AfterEach, eliminating lock leaks between tests. Closing; the further test hardening stays tracked in PR #2102.
Optimize TrackingFileManager unit tests and fix potential lock leaks (#…