fix(search): preserve dynamic scan ordering#13
Merged
Conversation
Defer independently inserted older history until a forward search reaches the true source prefix, and prioritize newer append ranges during backward scans even after an earlier append was partially consumed. Fill bounded search windows across short ViewFile reads so reverse scans cannot consume different coordinates than they inspected. Add regressions for huge tail records, multi-append ordering, reset boundaries, short reads, and search-index rebuilds.
siriusctrl
marked this pull request as ready for review
July 22, 2026 11:09
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
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.
Summary
Independent review fixes for #12's dynamic search-span state machine.
Insertedhistory during forward wrap until the true older boundary is loadedViewFile::read_windowresults, and reject zero/oversized reads instead of consuming the wrong coordinatesRoot causes
A forward search starting at loaded line zero could consume a multi-chunk initial tail before the first older insert. With no
Wrappedspan to absorb that insert, the newInsertedspan was scanned before the source's true prefix was known.A backward search consumes an appended span from its high end. After partial consumption, a later append is no longer contiguous with that remainder and must be queued before it; the previous insertion point queued it after the older remainder.
A short reverse
read_windowreturns the low side of the requested range, while the span consumer removes from the high side. Repeating bounded reads to fill the chunk keeps inspected and consumed coordinates identical.Review evidence
The backward
at == span.endboundary is covered directly: an inserted range is visited before the remaining wrapped span. The real nonzero reset boundary is also covered end-to-end: backward search visits the reset tail before its lazily inserted prefix. This path was already ordered correctly because the reset tail'sAppendedspan stays above the insertion boundary.Validation
cargo fmt --all --checkcargo check --workspace --all-targets --lockedcargo clippy --workspace --all-targets --locked -- -D warningscargo test --workspace --all-targets --lockedcargo test --workspace --doc --lockedRUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --lockedgit diff --check origin/fix/search-appends-v061...HEADbenches/load-performance.sh --samples 1 --case timelineTimeline smoke medians: tail open 0.676 ms, older prepend 1.640 ms, append refresh 2.404 ms, follow refresh/render 2.966 ms.