feat: readMany bulk read on VaultStore and Router - #44
Merged
Conversation
One `cat-file --batch` for N docs instead of N forks, with an answer that is element-wise indistinguishable from the reads it replaces. The conformance kit carries the guarantee: order, in-place nulls, duplicate paths, clamp parity, no mutation, router tagging, and - via a new optional round-trip counter on the target - the one-round-trip budget itself. Both stores pass it, and the differential fuzz now replays readMany too.
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.
Contract ADDITION (no behavior change to any existing verb):
readMany(paths, opts?)onVaultStoreandRouter.S-D item 1 of the simplification plan: the host's project/enrich paths read a whole folder page one doc at a time, so one REST default forks ~200 git processes. This gives them the bulk verb; the host fan-out is the consumer's follow-up.
Semantics - element-wise identical to
readnullwhereverreadwould answernull(missing doc, unsafe path){ clamp: false }includedunavailablefor the WHOLE call - no element is ever degraded to a null@vault/pathas usual, permission-gated exactly likeread- every ref is parsed and authorized before any container call, so one bad ref refuses the batch at zero IOImplementations
cat-file --batchthrough the existingbatchRead- warm budget 1 spawn, whatever N is.readandreadManynow share oneviewOfso they cannot drift.Conformance-first
New
readManyblock in the shipped contract suite - order/nulls, N-read equivalence, duplicates, clamp parity, empty request, unsafe paths, no mutation, and router parity. Both stores pass it unchanged.ConformanceTargetgains an optionalmakeCounted(store + live round-trip counter), so the kit PROVES the budget instead of trusting the implementation:readMany(N)costs no more than a singleread, and an empty request costs nothing. The security suite now fires the hostile-path corpus atreadManytoo, and the differential fuzz replays it against both stores.Perf (harness, PERF_SCALE=1000)
New gate row - 200 docs out of a 1000-note vault:
~29x, and 1 git process instead of 200. The second row is a ratio against a measured single read in the same run, so it stays honest on a slow runner.
Version
Minor-bump territory (1.1.0) - a consumer implementing
VaultStoremust add the verb. NOT bumped here; the coordinator owns the release.Verify: type-check + lint + format + 249 tests + coverage + build + dist smoke green locally.