Conversation
This is useful in situations where a hash of a large file is needed, but the file is processed non-sequentially (such as blocks being downloaded in parallel). The hash can be built up in any order but still produce the same value for the same input data.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Block alignment is not fully enforced, and sequential offsets can overflow on 32-bit targets.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review tier: Balanced
Findings: 1
New issues introduced by this change (5)
| Severity | Finding |
|---|---|
crates/commutative_hasher/src/lib.rs — This cumulative offset can overflow on 32-bit targets after a sequential stream exceeds 4 GiB.… |
|
crates/commutative_hasher/src/lib.rs — The documented alignment contract is not enforced for data.len(). Any short slice is accepted at… |
|
crates/commutative_hasher/src/lib.rs — This 128 MiB hashing test runs in the default suite, despite the repository's explicit `make… |
|
crates/commutative_hasher/README.md — The subject is singular, so “always get” should be “always gets.” |
|
crates/commutative_hasher/README.md — This Rust example cannot compile: ... is not Rust syntax and no digest value is initialized… |
What changed in this PR
Adds a commutative, block-based Rust hasher supporting parallel and out-of-order processing.
Changes:
- Adds parallel/sequential hashers and digest serialization.
- Adds tests, documentation, and workspace integration.
- Adds optional serde support.
| File | Description |
|---|---|
README.md |
Lists the new crate. |
Makefile |
Tests serde support. |
crates/commutative_hasher/src/lib.rs |
Implements hashers, digests, and tests. |
crates/commutative_hasher/README.md |
Documents usage and behavior. |
crates/commutative_hasher/Cargo.toml |
Defines crate metadata and dependencies. |
Suppressed comments (1)
crates/commutative_hasher/src/lib.rs:542
- This parameterized test hashes and allocates 128 MiB six times in every default test run, and the serde command runs it all again. The repository routes expensive tests through
make test-ignored(Makefile:44-48); please mark this test ignored or use a much smaller multi-block fixture.
#[rstest]
fn test_hash_large_value_sequential(#[values(1, 2, 8, 10, 60, 200)] num_chunks: usize) {
let expected_digest = "ee7338897f6eaf9b4f26b6ec33d3192bca8231485ac70d64fc81128397af0755";
let data = generate_data(1 << 27); // 128 MiB
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // Convert the CommutativeHashDigest to a string and serialize it | ||
| let s = self.hex_digest(); | ||
| serializer.serialize_str(&s) |
There was a problem hiding this comment.
any reason for using a hex string here instead of bytes and letting serde doing the encoding?
| hash.update(to_padded_bytes(start)); | ||
| hash.update(to_padded_bytes(len)); |
There was a problem hiding this comment.
would it be enough to just hash the end?
| // The calculation of the hash and point take a while, so they are done separately before | ||
| // locking the mutex to minimize contention. | ||
| let mut start = start_byte; | ||
| let chunk_hash = data.chunks(self.block_size).fold( |
There was a problem hiding this comment.
what happens if data is empty? would this still process a chunk (an empty one)?
Is the default commutativehashbuilder returning a "zero" elliptic curve point?
| // The start and length are added to ensure that blocks are not reordered. | ||
| scratch.update(to_padded_bytes(self.scratch_start)); | ||
| scratch.update(to_padded_bytes(self.scratch_size)); |
There was a problem hiding this comment.
this is not a good comment... rather reference that this is to make the hash compatible with the parallel version
| digest = "0.11" | ||
| hex = "0.4" | ||
| parking_lot = "0.12" | ||
| serde = { version = "1.0", features = ["derive"], optional = true } |
There was a problem hiding this comment.
often serde is added a feature (maybe check what we do in the other crates)
| - [`geo_filters`](crates/geo_filters): probabilistic data structures that solve the [Distinct Count Problem](https://en.wikipedia.org/wiki/Count-distinct_problem) using geometric filters. | ||
| - [`bpe`](crates/bpe): fast, correct, and novel algorithms for the [Byte Pair Encoding Algorithm](https://en.wikipedia.org/wiki/Large_language_model#BPE) which are particularly useful for chunking of documents. | ||
| - [`bpe-openai`](crates/bpe-openai): Fast tokenizers for OpenAI token sets based on the `bpe` crate. | ||
| - [`commutative_hasher`](crates/commutative_hasher): hash function that handles receiving data out-of-order. |
There was a problem hiding this comment.
This summary is not great. It's more about hashing large blobs in parallel.



This is useful in situations where a hash of a large file is needed, but the file is processed non-sequentially (such as blocks being downloaded in parallel). The hash can be built up in any order but still produce the same value for the same input data.