Repository navigation
test: file_locking_test asserts a 0.04s wall-clock budget — fails 2 of 13 runs on unmodified base #13366
Description
Activity
Already fixed on
Dev_new_gui— no change needed.The 0.04s budget at
autobot-backend/utils/file_locking_test.py:413was replaced in 3726bc6 (PR #13340, under #13162) with exactly the rendezvous approach this issue proposed: every writer parks inside its own critical section until all five are inside simultaneously, then assertspeak_concurrency == writer_count. No clock involved. The old<0.04sconstant survives only in the docstring, as the rationale.Verified on current base while working #13399 (PR #13444):
- 20 consecutive runs, 20 passed / 0 failed — versus the 2-of-13 failure rate measured here.
- Still able to fail. Seeded a real regression of [Concurrency] Fix File Writing Without Locking #514 by collapsing
_get_file_lockto return one shared lock for every path:
E AssertionError: Writes to different files are serialized: only 1 of 5 per-file locks were held at the same time E assert 1 == 5 FAILED autobot-backend/utils/file_locking_test.py::TestConcurrentFileWriteSafety::test_different_files_can_write_concurrentlySo the conversion is genuine, not a test that can no longer fail.
The issue's closing suggestion — "worth applying the same treatment to the other wall-clock flappers while in the area" — is picked up by #13444, which fixes the #13399 pair plus two sibling JWT
expassertions the sweep found. The remaining 68 are filed as #13445: an AST sweep found 73 elapsed-vs-literal assertions and not one carries theperformancemarker, so every wall-clock budget in the repo runs on the PR gate.This issue can be closed once #13444 merges, or now on the strength of 3726bc6.
- added a commit that references this issue
on Aug 4, 2026 No code change was needed — verified rather than assumed.
The 0.04s wall-clock budget this issue reports was already converted to a rendezvous proof in
3726bc69f(PR #13340):test_different_files_can_write_concurrentlynow proves concurrency by rendezvous rather than by elapsed time. Its docstring records the reasoning, citing #13162.Confirmed during the #13399 work: 20/20 runs pass, and the test still fails correctly when per-file locks are collapsed into one shared lock — so it has not become a test that cannot fail.
Closing as already delivered. The wider class of 73 wall-clock assertions is tracked in #13445.
Finding
autobot-backend/utils/file_locking_test.py:413test_different_files_can_write_concurrentlyasserts a 0.04s wall-clock budget.Measured on unmodified
Dev_new_gui: failed 2 of 13 runs.A wall-clock assertion that tight is not testing concurrency — it is testing whether the machine was briefly busy. It appears in the standing flapper set alongside
system_benchmarks,performance_benchmarksandpii_pipeline p99, all of which share the same shape.Why it is getting worse
PR #13356 converts two source-grep tests in this same file into genuine 20-thread race tests (for the
#513and#481locks). That is the right conversion — but it adds real thread contention to the file, so this timing assertion will fire more often.Fix
Assert the property, not the duration. The test wants to show that two writers to different files do not serialise against each other. Options:
threading.Eventon entry and assert both are set before either exits — proves overlap directly, with no clockEither survives a slow or loaded runner, which an 0.04s constant cannot.
Worth applying the same treatment to the other wall-clock flappers while in the area: they cost real signal, because a suite with known-flaky tests trains everyone to re-run rather than investigate.
Discovered during
Review of PR #13356, measured on unmodified HEAD across 13 runs.
Related