Skip to content

test(windows): force distinguishable mtime in concurrent-merge abort test (closes #645)#739

Merged
pandas-studio merged 1 commit intomainfrom
fix/windows-mtime-abort-test-645
May 3, 2026
Merged

test(windows): force distinguishable mtime in concurrent-merge abort test (closes #645)#739
pandas-studio merged 1 commit intomainfrom
fix/windows-mtime-abort-test-645

Conversation

@pandas-studio
Copy link
Copy Markdown
Collaborator

Summary

  • test_aborts_on_mtime_change is 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_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 and the abort branch never fires.
  • 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 (separate mm context sync run, user editing in editor) is naturally well above the threshold — this only covers the test-induced race.
  • Test-only change, no production impact.

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.py failures. The latest Windows CI run on main (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 single test_context_settings.py::test_aborts_on_mtime_change failure remained, and this PR closes it.

Test plan

  • uv run pytest packages/memtomem/tests/test_context_settings.py -v — all 35 tests pass on macOS
  • uv run ruff check + ruff format --check — clean
  • Windows CI matrix — should drop from 1 failure to 0

References

🤖 Generated with Claude Code

Copy link
Copy Markdown
Owner

@memtomem memtomem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]>
@memtomem memtomem force-pushed the fix/windows-mtime-abort-test-645 branch from e19c4d1 to 13a7d38 Compare May 3, 2026 08:15
@pandas-studio pandas-studio merged commit 0162e41 into main May 3, 2026
9 checks passed
@pandas-studio pandas-studio deleted the fix/windows-mtime-abort-test-645 branch May 3, 2026 08:28
@github-actions github-actions Bot locked and limited conversation to collaborators May 3, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows: config_signature unchanged after write — NTFS mtime resolution / cache

2 participants