Repository navigation
fix(tests): keep same-size edits out of the stamp time tick - #508
Conversation
Windows file times advance in ~16ms ticks, so a same-size rewrite landing in the tick that produced the recorded stamp reproduces size and mtime exactly — the stat fast path rightly calls that fresh, and NeedUpdateChecksAllContexts / SerializedStampsValidate failed deterministically on both Windows runners (main is red since #507). Production stamps are immune: merge only stamps files untouched since two seconds before the build, so a later edit can never share their tick. The tests defeat that guard on purpose via generous_build_at; bump the mtime explicitly after same-size edits so the verdict rests on the hash layer, which is what these assertions exercise.
📝 WalkthroughWalkthroughMerged-index tests now explicitly adjust dependency file modification times after rewrites and edits, ensuring update decisions consistently exercise the intended mtime and content-hash validation layers across platforms. ChangesMerged-index freshness validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
tests/unit/index/merged_index_tests.cpp (1)
740-740: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider asserting
set_file_mtimereturn values.
set_file_mtimereturnsfalseon failure (e.g., file doesn't exist, permission error). If it silently fails, the mtime isn't bumped and the test may pass or flake for the wrong reason. AnASSERT_TRUE(set_file_mtime(...))would catch this. This is a pre-existing pattern (lines 769 and 794 also ignore the return), so it's not blocking — just noting for future hardening.Also applies to: 748-748, 801-801
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/unit/index/merged_index_tests.cpp` at line 740, Assert that every set_file_mtime call in the affected test cases succeeds, including the calls near the existing updates at lines 740, 748, and 801. Wrap each invocation with ASSERT_TRUE so failures are reported immediately instead of allowing the test to continue with an unchanged modification time.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@tests/unit/index/merged_index_tests.cpp`:
- Line 740: Assert that every set_file_mtime call in the affected test cases
succeeds, including the calls near the existing updates at lines 740, 748, and
801. Wrap each invocation with ASSERT_TRUE so failures are reported immediately
instead of allowing the test to continue with an unchanged modification time.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: cca6267f-4bf7-48b1-bd85-ff8a3bc25d93
📒 Files selected for processing (1)
tests/unit/index/merged_index_tests.cpp
1 participant
Both Windows CI jobs are red on main since #507 (its own merge run 29258064794 failed):
MergedIndex.NeedUpdateChecksAllContextsandMergedIndex.SerializedStampsValidatefail deterministically withneed_update() expected true, got false.Root cause
Windows file times advance in ~16ms clock ticks. The failing assertions perform same-size rewrites (
int b2();→int b3();,int f();→int g();) moments after the stamp was recorded; when the rewrite lands in the same tick, the file reproduces the stamp's size and mtime exactly, so the stat fast path — equality-based by design — rightly reports fresh, and the hash layer the assertions meant to exercise is never consulted. On Linux/macOS nanosecond timestamps always move, which is why only Windows fails.Production is immune:
mergeonly records a stamp for files untouched since two seconds before the build (stat_baseline_before_ns), so a stamped file's later edit can never share its tick. The tests defeat that guard deliberately (generous_build_at()= now + 10s) to earn the fast path, which is what exposes them to the tick.Fix
After each same-size rewrite, bump the file's mtime explicitly (
set_file_mtime, +5s) — modelling the reality that a genuine edit arrives long after the stamp, and pinning those verdicts on the hash layer as intended. Test-only change; no product code touched.