Boloop-made explanatory illustration: search the full eligible collection before splitting the result into pages.
A catalog with only a few items can look perfectly healthy. Search returns results, filters reduce the cards and there are no obvious gaps. Then someone looks for an older item and discovers that it still exists in the system but cannot be found in the catalog.
Boloop addressed a truncated catalog during early backend regression work. The fix was not simply another “load more” button. We needed to establish that a query covered the entire eligible collection, rather than the small slice already loaded by the browser.
This is worth testing while a collection is still small. Otherwise, the page can keep looking normal while missing content never gets a chance to be noticed.
Distinguish records not fetched from records filtered out
An item may be absent for several reasons. It may be unpublished or non-public. Search may inspect the wrong fields. A request may fetch only the first page. Sorting and pagination boundaries can also omit or repeat records.
These causes require different fixes. Treat “it exists in the admin” as a clue, then check whether it has a public published snapshot, matches the selected type and filters, and actually appears in the request result.
Boloop’s early repair explicitly replaced the truncated public catalog with validated server-side queries and pagination. Search, filters and sorting therefore operate on content the server may publish, rather than the card array currently held by the browser.
In that order, pagination divides an already defined result set into sections. It cannot reduce the dataset first and then pretend it searched everything.
Query parameters are part of the interface
A recoverable catalog needs explicit state for the query, type, sort order and page position. After navigating pages and going back, a reader should return to the previous result. Changing language should not inexplicably discard the search.
The server must validate parameters too. Page size and offset should stay within permitted bounds, and filters should belong to the supported set. Invalid values should be rejected clearly, rather than silently producing an arbitrary default that looks as if the request was honored.
Another easily missed detail is that results and facet counts need compatible public-visibility rules. Otherwise, even if no private body is exposed, filter statistics can reveal hidden content. Our isolated regression checks included keeping hidden records out of public facets.
Test data needs to cross the real boundary
That independent check prepared 205 public test records and retrieved them in batches of 100, 100 and 5, verifying that nothing was repeated or omitted. The 205 records were an isolated test dataset, not the live site’s content count.
The choice matters: the dataset exceeds one page and two pages, then leaves a partial final page. Twenty records could completely miss a defect that affects everything beyond the first hundred.
Counts alone are insufficient. Three pages can add up to the right total while repeating one record and omitting another. Comparing the returned IDs with the expected ID set answers the completeness question.
The same round checked matching when a locale field was absent, invalid filters and hidden content entering public results. Each check addressed the same underlying question: what collection is this catalog actually querying?
Walk through cross-page use in a browser
A correct API result does not establish a usable catalog. Actual browser acceptance used a different isolated dataset of 37 records: 24 on the first page and 13 on the second. Back returned to the first page, and Forward reopened the second.
The browser then searched for a specific item independently of its current page position and returned only that item. Switching to English preserved the query and displayed the corresponding language content. Sorting and type filters were checked separately too.
The smaller dataset exercised the interaction journey, while 205 records checked completeness across pages. They served different purposes and should not be merged into one testing number.
We also injected a database failure after the catalog loaded, then submitted a search. The page showed an error and retry action while retaining the URL and input. After restoring the data source, retrying on the same page returned the target record. A failed request should not erase the reader’s search intent.
Give your own catalog a focused check
If you are building a tool directory, article library or portfolio, select a recent item and the oldest item. Confirm that both qualify for public access, then reach them through the homepage, catalog and search. Next, use an isolated dataset that exceeds the pagination limit and compare the full result set.
Finally, follow the browser journey: change pages, search, clear conditions, change language, go back and forward, and retry after a request failure. Check that state remains coherent, not merely that each step produces cards.
This Boloop repair and acceptance took place in the early isolated cloud environment. We did not populate production with test records or measure production throughput or Worker memory limits. The supported conclusion is specific: the catalog queries, pagination completeness and browser recovery paths that were checked passed verification.
Keeping that conclusion specific makes it clear what to test again as the collection grows. Catalog reliability then becomes something to examine before a reader reports that an item is missing.