Search views stop at 250 results because the Typesense adapter requests one page at the server's per-page maximum

[jamiefolsom]

On Global Writing Cultures (FairData Sites v1.11.0, @performant-software/core-data 3.1.25), the Geopolitical Contexts search shows "250 results" while the events collection holds 433 documents and Typesense reports found: 433 for the same query. The list, the map, and the timeline all stop at 250. Items has the same problem in waiting: 704 documents, so it also shows 250.

Cause

The Typesense InstantSearch adapter is created with additionalSearchParameters.limit: e.limit || 250 and the map view loads hits through useInfiniteHits without paging past the first page. Typesense treats limit as an alias for per_page and refuses anything above 250 (Only upto 250 hits can be fetched per page), so raising the value in a site's config.json is not a way out; the cap is the server's, and it applies per page, not per query.

Fix

Page through the results. For the map and the timeline, request pages of 250 until found is reached (or until a sensible ceiling, with the count shown honestly as "showing N of M"), and derive the result count from found rather than from the number of hits loaded. The list view already pages at 50 and only needs its count to come from found.

Observed September 2, 2026 on https://gwc.performant.studio/en/search/events/.

[jamiefolsom]

Correction after more testing: this is not a general cap, and the mechanism I described is wrong in part.

On the same site, the Items search shows 704 results, which is the true found for that collection. Only the Geopolitical Contexts (events) search shows 250 against a collection of 433. The adapter sets nbHits from Typesense's found (index.es244.js line 226), so the events page is genuinely receiving a response with found: 250, while a direct query to the collection with the same q=*, query_by=name, per_page=250, sort_by=name:asc, and the site's three facet_by fields returns found: 433 every time. So something in the events page's actual query differs from that replica.

The only configuration difference between the two searches is that events declares typesense.facets.include (start_year_facet, end_year_facet, b9190c82-….name_facet) and drives its timeline from start_year_facet, while items declares a facet list and a timeline with an event_path. A range refinement applied by default, or some other parameter the events widgets add, is the likely cause. The exact multi_search request and response from the events page would settle it; I could not capture them from outside the browser.

The title of this issue still describes a real limit for the map and timeline views, which load at most one page of 250, but the visible count discrepancy has a different cause.

[jamiefolsom]

Update the next morning: the same events search now shows 433 results with no change on our side, so the 250 was transient. The likeliest explanation is a cached response: the adapter caches search results for 120 seconds, and the count we saw may have come from a query answered while the collection was in an intermediate state. We will watch whether it recurs right after a scheduled index run; if it does, the indexer's batch upserts are becoming visible mid-run and the fix belongs on the connector.

What remains of this issue is the original observation about the map and timeline views loading at most one page of 250 hits. That still needs confirming on a collection larger than 250 — Items on this site, with 704 documents, is a good test.