Flaky: checkout_touches_only_what_differs_and_renders_in_batches under load issue #166 open andymccall opened this · 1 comment
andymccall set labels bug ·
Finding (2026-11-04, from the failing run's output): the two builds differ in one file's node identifier, not in content. With the test's 2000 files under f/, the changed-only build adds f/1302.txt with a fresh identifier, while the full build adds it with an identifier that already appeared earlier in the same build's tree ops (normalised as N557, the position of a file added hundreds of entries before). Everything before 1302.txt matches.
So under load the full build reused, for 1302.txt, an identifier the previous working-copy version had given another path: reuse (added_node_paths(&old_wc, …)) or new_node/reused_node handing the same NodeId to two paths. Random NodeIds are 16 bytes, so this is not a collision. Load matters because the previous snapshot it reuses from was taken while files were still being written (racy-clean), which can leave the old working copy naming a node under a path it no longer has.
Next: log reuse when the assertion fails (path → node, and which other path holds the same node), and check path_of_node for two paths resolving to one node when a directory's entries change between snapshots. Not fixed yet.
repo::tests::checkout_touches_only_what_differs_and_renders_in_batchesfailed once in the local gate (2026-11-03) while the hub's gate ran beside it: "a changed-only build is the full one" (crates/oxy-core/src/repo/snapshot.rs:911). Alone it passes (3 of 3), but takes about 150 s under load against the suite's usual seconds.Likely: the changed-only build trusts file times, and on a loaded machine a file written in the same tick as the snapshot reads as unchanged or changed. The test should not depend on timing: set the times it relies on explicitly, or make the check it asserts robust to a racy-clean file.