refactor: split the two senses of "batch" into load and decryption batch - #2601
Open
zancas wants to merge 7 commits into
Open
refactor: split the two senses of "batch" into load and decryption batch#2601zancas wants to merge 7 commits into
zancas wants to merge 7 commits into
Conversation
Pepper-sync used one word for two units. The batcher's unit is a maximal contiguous sequence of whole blocks whose combined output count stays within a budget: it is now a load, built by the Loader, bounded by max_load_outputs and MAX_LOAD_NULLIFIERS. The trial-decryption unit is a flattened, transaction-aligned buffer of one pool's outputs, indifferent to block boundaries: it keeps batch, qualified at the types as DecryptionBatch, DecryptionBatchRunner, and friends, staying continuous with the upstream zcash_note_encryption batch API it wraps. Bare "batch" inside the runners module still reads unambiguously as the decryption sense, so module-local prose and locals keep it. The worker-side budget takes the neutral name max_outputs, because scan derives both the decryption batch size and the located-tree build size from it; only the value handed to the runners is decryption_batch_size, retiring the inverted trial_decrypt_task_size name. The crate docs and mermaid diagrams follow the split, and the loading step's description now states the true cut rule: a load is cut at the last whole block that keeps the output budget unexceeded, rather than "a fixed number of outputs". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
zancas
marked this pull request as ready for review
July 30, 2026 03:53
The repro merged by PR #2598 (commit c47b6fc) left zero_ironwood_seam_bounds_rebase_from_first_block_metadata red on every descendant branch, which is the CI failure on PR #2601's test shard 7. InitialScanData::new trusted the start seam block's final tree sizes verbatim, so a wallet block persisted before the bounds tracked the Ironwood pool handed the scan a zero baseline that the understated-baseline rejection then correctly refuses. A zero ironwood seam bound now counts as untracked rather than empty. When the seam reports zero, the baseline re-derives from the first compact block's chain metadata: the final tree size minus the outputs the block itself serves. A genuinely empty tree, where the metadata is also zero, keeps its zero baseline, and nonzero seam bounds pass through unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Pepper-sync used one word for two different units. This change gives each its own name, stacked on #2599.
The batcher's unit is a maximal contiguous sequence of whole blocks whose combined output count stays within a budget — the block that would cross the line starts the next unit. It is now a load, built by the
Loader, bounded bymax_load_outputsandMAX_LOAD_NULLIFIERS. The trial-decryption unit is a flattened, transaction-aligned buffer of one pool's outputs, indifferent to block boundaries. It keeps batch, qualified at the types asDecryptionBatch,DecryptionBatchRunner, and friends, staying continuous with the upstreamzcash_note_encryption::batchAPI it wraps; bare "batch" inside the runners module still reads unambiguously as the decryption sense, so module-local prose and locals keep it.The worker-side budget takes the neutral name
max_outputs, becausescanderives both the decryption batch size and the located-tree build size from it; only the value handed to the runners isdecryption_batch_size, retiring the invertedtrial_decrypt_task_sizename. The crate docs and mermaid diagrams follow the split, and the loading step's description now states the true cut rule — a load is cut at the last whole block that keeps the output budget unexceeded — replacing the previous "a fixed number of outputs" wording, which described the mechanism incorrectly.The rename is behavior-preserving and entirely
pub(crate)-internal: no public API surface changes.🤖 Generated with Claude Code