Skip to content

fix(core): stop reading a capped search page as the end of results - #78

Open
mimi1vx wants to merge 1 commit into
plusky:mainfrom
mimi1vx:bugz_api_f
Open

fix(core): stop reading a capped search page as the end of results#78
mimi1vx wants to merge 1 commit into
plusky:mainfrom
mimi1vx:bugz_api_f

Conversation

@mimi1vx

@mimi1vx mimi1vx commented Aug 9, 2026

Copy link
Copy Markdown
Collaborator

Summary

Guard::quicksearch_window treated any upstream page shorter than the
requested chunk as end-of-results. Bugzilla is free to cap a page below
the requested limit (an admin-configured max_search_results), so on
a 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

  • Only an empty page now ends the scan (returned == 0), not a short
    one.
  • Added an explicit SEARCH_SCAN_REQUESTS = 10 bound so the request
    count no longer depends on the server returning a full 200-row
    chunk. Whichever of rows/requests binds first still truncates, same
    as before.
  • Updated rustdoc on quicksearch_window to state both bounds
    independently and explain why a short page is not end-of-results.
  • Test fixtures that served the same static page at every offset
    (guard_wiremock.rs, audit_wiremock.rs::mount_fixture,
    tools_wiremock.rs::mount_search and one ad hoc mock) now honor
    offset so they behave like a real paginated Bugzilla instead of
    replaying forever under the new loop semantics.
  • docs/DESIGN.md restates the two bounds and records the short-page
    rule.

Breaking Changes

None. quicksearch_window's signature is unchanged; SEARCH_SCAN_REQUESTS
is 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, a
    100-row server cap, limit=5, offset=150 returns ids 151..=155.
  • quicksearch_window_capped_page_still_bounds_requests: pathological
    1-row cap over 5000 bugs still costs exactly 10 upstream requests and
    serves the 10 scanned bugs.
  • Full gate: 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.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant