Ember Data Store and JSON:API Adapter interoperability for bounded queries and large dataset pagination

Direct answer

When successive bounded store.query calls return overlapping records, the Ember Data identity map reconciles them by type and id. Existing record instances are reused, new ids are added, and normalized attributes from the later response are pushed into the already-loaded records. Records absent from a later page are not evicted simply because they were omitted. This behavior is part of the Store contract, but the exact merge semantics for relationships and locally dirty attributes depend on the installed Ember Data major version and serializer; verify against your version before relying on edge-case merge behavior.

To surface pagination metadata without coupling to a specific adapter, preserve the JSON:API document contract in your serializer. In normalizeQueryResponse, keep top-level meta and links so they are accessible as result.meta and result.links on the AdapterPopulatedRecordArray. Treat next, prev, first, last, and any page or cursor meta fields as response data, not adapter internals.

For cursor pagination, the client must own the current cursor or next link, page size, sort/filter parameters, and an invalidation rule for mutations or refresh. Pass the cursor back in the next query hash. The Store does not chain pages or maintain a virtual collection.

Confirmed facts vs. version-sensitive behavior

Confirmed by the Store contract: store.query forwards the query hash to the adapter and returns an AdapterPopulatedRecordArray. The Store does not inject page, size, or cursor limits and does not automatically fetch subsequent pages.

Likely and version-sensitive: whether attribute updates for already-loaded records replace or merge relationships, and whether locally dirty records are overwritten, vary across Ember Data major versions. backgroundReload and coalesceFindRequests are not pagination controls. backgroundReload may re-run a route query and merge results into the identity map; coalesceFindRequests concerns findRecord coalescing.

Steps for this case

1. Confirm the installed Ember Data version and review its changelog for query metadata and backgroundReload semantics.
2. Inspect normalizeQueryResponse in your JSON:API serializer to ensure top-level meta and links are preserved.
3. Store the current cursor (or next link) and query parameters in application state; pass them back on the next store.query.
4. If using backgroundReload, decide whether entering the route should re-request the first page or the current cursor, and keep that state outside the query or inside it deterministically.
5. Remember that the identity map is not an eviction policy; large datasets can still grow unless records are explicitly unloaded or queries are narrowed.

Verification

Run a local JSON:API server that returns overlapping ids plus top-level meta and links. Assert that result.meta and result.links are present and that duplicate ids update a single record instance. Re-enter the route with backgroundReload enabled and confirm whether the same cursor or the first page is requested.

Missing diagnostic

What Ember Data major version is installed? The answer changes only if you are on a version where query metadata handling or backgroundReload merge behavior differs materially from the current documented contract.