iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Repeated or missing map results across pages can come from offset pagination reading a changing index, unstable sort order, mismatched continuation state, or a cache serving responses for different searches. A cache is one possibility, not a diagnosis: compare the exact spatial query, filters, ordering, page size, and page token across requests before changing the implementation.
How pagination creates duplicates or skips
Offset pagination asks for a range such as results 1–20, then 21–40. If the search index changes between those requests, the second range may no longer follow the first. For example, a newly matching document inserted ahead of the page boundary can shift existing results down one position. The last result from page one may then appear again on page two; related shifts can also leave a result out of the traversal.
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
OpenSearch documents this behavior for from/size: those parameters are stateless, and each request uses the latest available data. Its documentation states, “The from and size parameters are stateless, so the results are based on the latest available data.” OpenSearch: Paginate results
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →That is an index-consistency problem, even if a cache makes it look like a cache defect. A cached first page and a freshly computed second page can represent different index states. Conversely, a cache may return the wrong page if its key omits a query parameter that changes which records match or how they are ordered. Both are plausible failure modes; without a specific application or request trace, neither can be identified as the cause.
#1 Best Overall
What a geo-search cache must keep aligned
For each page request, record a request fingerprint and compare it with the preceding request. Include the normalized spatial input—not just a human-readable place name—along with its coordinate reference assumptions, filters, sort, page size, and continuation state. Record an index or query version if the service exposes one. Compare returned feature identifiers and ordering as well as the request fields.
- Spatial input: exact geometry or bounding box, normalized consistently, plus the coordinate reference assumptions used to interpret it.
- Membership filters: every filter that can include or exclude a feature.
- Ordering: the full sort definition, ideally including a stable unique tie-breaker supported by the backend.
- Page state: offset, cursor, continuation token, or server-generated next link, and the page size.
- Index state: whether writes or refreshes occurred during traversal and whether the API promises a consistent snapshot.
- Cache behavior: the cache key, expiry, and whether each response was a cache hit or a newly executed search.
Check that cache keys distinguish requests whenever a change can affect result membership or order. Check that a next link or token remains associated with the original query rather than being reused with altered filters, bounds, sorting, or page size. These are implementation-audit steps, not evidence that any particular cache key is defective.
Continuation tokens need the same query and stable ordering
A continuation token is meaningful only in the context of the query and sort that produced it. MongoDB Search advises rerunning the same query semantics when using its search-after token, and notes that documents tied on sort values can appear in arbitrary order. If tied documents change order between requests, a cursor can skip or repeat records even when the query text appears unchanged. MongoDB Atlas Search: Paginate Results
Free tools Windows power users keep installed
One-click scans. No signup required.
As an audit check, determine whether the sort has a unique, immutable tie-breaker and whether the backend supports it. A timestamp or relevance score alone may not uniquely order records. Elasticsearch likewise warns that a unique sort tie-breaker helps avoid missing or duplicate hits when paginating with search_after. The exact fields and syntax depend on the deployed backend and version. Elasticsearch: Paginate search results
Geo-feature paging may use server-side result caches
Some geospatial feature services provide next- and previous-page links and retain a result set server-side while a client traverses it. OGC Web Feature Service 2.0 defines an exception for an expired cached result set. It also specifies that services advertise cache timeout information and whether paging is transactionally consistent. That makes expiry and consistency part of the paging contract, not merely an internal cache detail. OGC Web Feature Service 2.0 Interface Standard
When a service reports that a result cache has expired, follow its documented recovery behavior rather than assuming an old next link remains valid. If the service does not promise transactionally consistent paging, results can change during traversal; treat that separately from malformed cache keys.
Choose pagination for the depth and consistency you need
| Approach | Useful when | Consistency and ordering considerations | Limit or trade-off |
|---|---|---|---|
Offset (from/size, or equivalent) |
Shallow pages, especially when occasional index changes during traversal are acceptable. | Each page may use the latest index state; stable ordering alone does not freeze the dataset. | Service-specific depth limits apply. OpenSearch documents a 10,000-result limit for this method; Elasticsearch’s default index.max_result_window is 10,000 hits. OpenSearch documentation; Elasticsearch documentation |
| Cursor or search-after continuation | Sequential traversal or deep pagination when the backend provides a continuation mechanism. | Keep query semantics and sort identical; use a stable unique tie-breaker where supported. A cursor alone does not necessarily preserve a snapshot. | Token lifetime and snapshot behavior are backend-specific. Elasticsearch recommends search_after with a point in time for deep pagination that must preserve index state. |
| Scroll or retained search context | Processing large result batches where a stable traversal matters more than interactive, real-time navigation. | OpenSearch describes a scroll context whose batches do not change when new data arrives during that context. | It holds search context for a period of time. Elasticsearch says scroll is for processing large amounts of data rather than real-time user requests. |
The 10,000 figures above are specific documented service limits, not a universal pagination threshold. OpenSearch limits from/size to 10,000 results; Elasticsearch’s 10,000-hit value is its default result-window setting, which can be configured. Amazon CloudSearch separately documents a maximum of 10,000 hits reachable with start and size, requiring a cursor beyond that. Amazon CloudSearch: Paginating results
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteBackend guidance also differs in what it says about consistency. OpenSearch describes scroll as keeping a search context for a period and returning batches that do not change with new data during that context. Elasticsearch recommends a point in time with search_after when deep pagination must preserve index state, and reserves scroll for bulk processing rather than real-time user requests. Amazon CloudSearch warns that stale cursors may return stale results and that score-sorted cursor requests can be inconsistent across index updates or eventually consistent replicas. Follow the guidance for the actual service and version; these methods are not interchangeable API rules.
Best Value
- Used Book in Good Condition
A practical investigation sequence
- Capture adjacent requests and responses. Log the normalized geometry or bounds, coordinate reference assumptions, filters, sort, page size, continuation value, cache status, and returned feature identifiers for each page.
- Compare query fingerprints. Verify that fields affecting membership or order are identical between pages, except for the intended offset or continuation state.
- Inspect ordering. Check for tied sort values and confirm whether a unique immutable tie-breaker is supported and included.
- Audit cache partitioning. Confirm that the key varies with every membership- or ordering-relevant parameter and that cached responses cannot be paired with continuation state from another query.
- Check index changes and snapshot guarantees. Establish whether writes, refreshes, or replica differences occurred between calls, and whether the backend promises a stable view for the chosen pagination method.
- Check expiry and recovery. For server-generated links or tokens, verify their lifetime and the documented response when the underlying result set expires.
- Match the method to the workload. Keep offsets for shallow lists only when their changing-view behavior is acceptable; use the backend’s supported cursor or snapshot approach for deeper or consistency-sensitive traversals.
This sequence separates four questions that are easy to conflate: whether the search itself changed, whether the order is deterministic, whether continuation state belongs to the same query, and whether a cache served a response outside its intended key or lifetime.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
