fix(core): stop reading a capped search page as the end of results - #78
Open
mimi1vx wants to merge 1 commit into
Open
fix(core): stop reading a capped search page as the end of results#78mimi1vx wants to merge 1 commit into
mimi1vx wants to merge 1 commit into
Conversation
quicksearch_window broke on returned < chunk to mean end-of-results, but Bugzilla may cap a page below the requested limit (max_search_results). On such an instance the scan stopped after one request and every visible bug past the first page became unreachable. Only an empty page now ends the scan; a separate SEARCH_SCAN_REQUESTS=10 bound caps sequential requests so the loop no longer depends on the server choosing a full page size.
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
Guard::quicksearch_windowtreated any upstream page shorter than therequested chunk as end-of-results. Bugzilla is free to cap a page below
the requested
limit(an admin-configuredmax_search_results), so ona capped instance the scan stopped after one request and every visible
bug past the first page became unreachable — truncation caused by the
server's page size, not by the result set actually ending.
Changes
returned == 0), not a shortone.
SEARCH_SCAN_REQUESTS = 10bound so the requestcount no longer depends on the server returning a full 200-row
chunk. Whichever of rows/requests binds first still truncates, same
as before.
quicksearch_windowto state both boundsindependently and explain why a short page is not end-of-results.
(
guard_wiremock.rs,audit_wiremock.rs::mount_fixture,tools_wiremock.rs::mount_searchand one ad hoc mock) now honoroffsetso they behave like a real paginated Bugzilla instead ofreplaying forever under the new loop semantics.
docs/DESIGN.mdrestates the two bounds and records the short-pagerule.
Breaking Changes
None.
quicksearch_window's signature is unchanged;SEARCH_SCAN_REQUESTSis a private constant. The only externally visible effect is that a
search against a page-capped Bugzilla instance can now issue up to 10
sequential upstream requests instead of stopping after the first.
Testing
quicksearch_window_survives_a_capped_page: 300 visible bugs, a100-row server cap,
limit=5, offset=150returns ids151..=155.quicksearch_window_capped_page_still_bounds_requests: pathological1-row cap over 5000 bugs still costs exactly 10 upstream requests and
serves the 10 scanned bugs.
cargo fmt --check,cargo clippy --workspace --all-targets --locked -- -D warnings,cargo clippy -p bugwarden --features gen --all-targets --locked -- -D warnings,cargo test --workspace --all-targets --locked(all pass),cargo deny check,typos.Related
None.