fix(driver-support): sort directory outputs before packing - #377
Merged
Conversation
A `Content::DirPath` output was walked with a bare `walkdir::WalkDir`, so its tar member order was `read_dir` order — hash order on ext4, insertion order on APFS, something else on tmpfs. That order is the artifact's hashout, so the same directory tree packed to two different hashouts on two machines: every downstream target folding it computed a different hashin, and the remote cache missed for byte-identical content. It surfaced as "heph is slow", never as an error, and it could also trip `reconcile_rebuilt_hashouts` into calling a rebuild's hashouts inconsistent with its manifest. `Content::Glob` was never affected (the glob crate sorts); `FilePath` has no order to get wrong. Sorted per directory via `sort_by_file_name` rather than by collecting the whole tree and sorting full paths — walkdir already buffers each directory's entries, so this reuses that buffer instead of allocating a second one. This rekeys every directory-output target on any machine whose readdir order differs from sorted, which is most of them. That is a one-time rebuild, and the alternative is a permanent cross-machine cache miss. The test creates its files in reverse order so an unsorted walk on an insertion-order filesystem reproduces exactly that order — it fails without the fix rather than passing by luck (verified on APFS). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WqQZxsTqanJRWLWdPSchBo
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
A
Content::DirPathoutput was walked with a barewalkdir::WalkDir, so its tar member order wasread_dirorder — hash order on ext4, insertion order on APFS, something else again on tmpfs.That order is the artifact's hashout. So the same directory tree packed to two different hashouts on two machines: every downstream target folding it computed a different
hashin, and the remote cache missed for byte-identical content. It surfaces as "heph is slow", never as an error. It can also tripreconcile_rebuilt_hashoutsinto declaring a rebuild's hashouts inconsistent with its manifest.Content::Globwas never affected (theglobcrate sorts).FilePathhas no order to get wrong.How
WalkDir::new(&dir_full).sort_by_file_name()— sorted per directory rather than by collecting the whole tree and sorting full paths, since walkdir already buffers each directory's entries and this reuses that buffer instead of allocating a second one.Impact
This rekeys every directory-output target on any machine whose readdir order differs from sorted, which is most of them. One-time rebuild; the alternative is a permanent cross-machine cache miss.
oci_pull(layout = True)is the case that surfaced it — an OCI layout directory is aDirPathoutput, and "the same layout hashes the same everywhere" has to hold before a daemonless image builder can claim reproducibility.Test
dir_output_packs_in_a_stable_ordercreates its files in reverse order on purpose: on an insertion-order filesystem an unsorted walk reproduces exactly that, so the test fails without the fix rather than passing by luck. Verified — without the sort it returns["out/z.txt", "out/sub/b.txt", "out/sub/a.txt", "out/a.txt"]on APFS.🤖 Generated with Claude Code
https://claude.ai/code/session_01WqQZxsTqanJRWLWdPSchBo