test(windows): force distinguishable mtime in concurrent-merge abort test (closes #645)#739
Merged
pandas-studio merged 1 commit intomainfrom May 3, 2026
Merged
Conversation
memtomem
approved these changes
May 3, 2026
Owner
memtomem
left a comment
There was a problem hiding this comment.
Test-only 12-line fix scoped exactly to #645 — explicit os.utime bump (+1ms) ensures the mocked second writer has a distinguishable st_mtime_ns regardless of OS timer granularity (NTFS via WriteFile reports system-clock resolution ~15.6ms). Comment correctly notes a real-world second writer is naturally well above this threshold so this only covers the test-induced race. Approving.
…test (closes #645) ``test_aborts_on_mtime_change`` was the last residual Windows CI failure from #645 — the test simulates a concurrent writer by patching ``_read_with_mtime`` to write to the target between the read and the production code's mtime re-check. On Windows the two ``write_text`` calls can land inside the same system-clock tick, so ``st_mtime_ns`` reports the same value for both writes and the abort branch never fires. NTFS native resolution is 100ns but ``WriteFile``-induced metadata updates use the system clock, which advances at ~15.6ms on typical Windows runners. Force a distinguishable mtime via ``os.utime(..., ns=(atime, mtime + 1ms))`` after the simulated write so the test deterministically exercises the production guard regardless of OS timer granularity. A real-world second writer (a separate ``mm context sync`` run, or a user editing in their editor) is naturally well above this threshold — this only covers the test-induced race. The other 16 ``test_web_hot_reload.py`` failures listed in #645 have already cleared on the latest Windows CI run (25264999636); only this single mtime-resolution case remained. Test-only change, no production impact, ruff clean, all 35 ``test_context_settings.py`` tests still pass locally on macOS. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
e19c4d1 to
13a7d38
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
test_aborts_on_mtime_changeis the last residual Windows CI failure from Windows: config_signature unchanged after write — NTFS mtime resolution / cache #645. The test simulates a concurrent writer by patching_read_with_mtimeto write to the target between the read and the production code's mtime re-check. On Windows the twowrite_textcalls can land inside the same system-clock tick, sost_mtime_nsreports the same value and the abort branch never fires.os.utime(..., ns=(atime, mtime + 1ms))after the simulated write so the test deterministically exercises the production guard regardless of OS timer granularity. A real-world second writer (separatemm context syncrun, user editing in editor) is naturally well above the threshold — this only covers the test-induced race.Why mtime collides on Windows
NTFS native FILETIME resolution is 100ns, but
WriteFile-induced metadata updates use the system clock, which advances at ~15.6ms on typical Windows hosts (default timer interrupt). Two writes within that tick get the same mtime even though the second strictly happened after the first. The fix bumps mtime by 1ms (1_000_000 ns) — well above the synthetic resolution, well below any real-world inter-process gap.Status of the broader #645 cluster
The issue body listed 17
test_web_hot_reload.pyfailures. The latest Windows CI run onmain(run 25264999636, 2026-05-02) reports 0 hot-reload failures — those have been cleared by previous Windows CI work (PRs #711, #713, #714, #716, #732). Only this singletest_context_settings.py::test_aborts_on_mtime_changefailure remained, and this PR closes it.Test plan
uv run pytest packages/memtomem/tests/test_context_settings.py -v— all 35 tests pass on macOSuv run ruff check+ruff format --check— cleanReferences
🤖 Generated with Claude Code