and cursors there is no get-all

Not specified by the original author.

TL;DR

Pass first up to 250 and walk the cursor pagination for larger catalogs. Request with first set to at most 250 and follow the pageInfo cursors until hasNextPage is false.

Steps

1. When you pull Shopify products over GraphQL, always paginate. Request with first set to at most 250 and follow the pageInfo cursors until hasNextPage is false. There is no total count shortcut that replaces this, so agents should loop the cursor walk rather than retrying a bigger single query.

When to use

You are seeing this: When you pull Shopify products over GraphQL, always paginate. Use this skill when you run into "Shopify GraphQL: page through products with first and cursors, there is no get-all".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #66185620 (accepted answer, 13 votes): the asker tried to fetch all products in one GraphQL query and hit must provide first or last errors. The accepted answer: neither the Storefront nor the Admin GraphQL API returns everything in one request. Pass first up to 250 and walk the cursor pagination for larger catalogs.

Verified resolution: When you pull Shopify products over GraphQL, always paginate. Request with first set to at most 250 and follow the pageInfo cursors until hasNextPage is false. There is no total count shortcut that replaces this, so agents should loop the cursor walk rather than retrying a bigger single query.

Source URL: https://stackoverflow.com/questions/66185620/graphql-shopify-get-all-products-or-totalcount-of-products

Not specified by the original author.

TL;DR

Remove the final fetched row, which is the oldest lookahead. Protect token version, endpoint, authenticated security boundary, canonical resource, canonical filters, direction, sort policy, snapshot, complete keyset position, and expiry. Keep the entire claim set opaque. Use authenticated encryption, or a random server-side handle of at least 128 bits authenticated before lookup.

When to use

You are seeing this: Query by the complete unique sort key in descending order for page size plus one. Use this skill when you run into "Secure backward pagination with context-bound cursors".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Trigger

Use this when storage is read newest-first with page size plus one, responses are returned oldest-first, and a client-held cursor may survive changes to the selected resource, filters, or direction.

Practical steps

1. Query by the complete unique sort key in descending order for page size plus one.
2. Detect overflow before changing order. Remove the final fetched row, which is the oldest lookahead.
3. Build the exclusive next position from the oldest retained row, then reverse only the retained rows for chronological output. Omit the cursor when there is no lookahead.
4. Protect token version, endpoint, authenticated security boundary, canonical resource, canonical filters, direction, sort policy, snapshot, complete keyset position, and expiry.
5. Keep the entire claim set opaque. Use authenticated encryption, or a random server-side handle of at least 128 bits authenticated before lookup. A readable signed payload provides integrity but not confidentiality.
6. On continuation, authenticate the token before trusting fields, recompute every request binding, reauthorize current access, and apply both the snapshot and exclusive position.
7. Return one generic invalid-cursor response for malformed, expired, mismatched, missing, or unauthorized state. Never echo or log tokens, claims, identifiers, or differing values.
8. Bound telemetry with a closed reason vocabulary and at most one warning per request. Permit only fixed dimensions such as endpoint and service version.

Snapshot requirement

A maximum display key is not automatically a stable snapshot. Backdated inserts, equal-key inserts, or keys allocated before commit can become visible later below the cursor. For append-only data, use a committed insertion watermark whose order matches visibility and constrain every page to the initial watermark. For stronger consistency, use an MVCC as-of view or materialized result. Freezing edits and deletes requires those stronger mechanisms or versioned rows.

Auxiliary effects

Keep background publication or sharing outside the primary pagination path. Absence of an acknowledgement does not prove that an external effect did not commit before a worker crash. If a worker can change visibility, use an authoritative durable gate or an idempotent durable outbox with status reconciliation and fencing. Let the primary request finish after a worker deadline, but do not infer sharing permission from an ambiguous outcome.

Limits

The design assumes a deterministic immutable composite order. Canonicalization must exactly match query semantics, including defaults, absence, types, duplicate handling, and ordered versus set-like values. Client-side cursor clearing improves usability but never replaces server validation. A high-water insertion watermark alone does not freeze updates or deletions.

Failure prevented

This prevents skipped boundary rows, duplicate traversal, reuse of a valid cursor against another resource or filter set, disclosure of sensitive cursor state, phantom rows caused by weak snapshots, high-cardinality diagnostic leakage, and incorrect fail-open behavior after an auxiliary worker crashes.

Supported by reasoned analysis in the cited conversation, including an independent reasoning review. No executable tests were run.

Rationale: A client-held position alone is unsafe when the user can switch resources or filters, and a display-key high-water mark can admit late-visible rows. The combined invariants are reusable across message timelines and similar append-oriented feeds.

Not specified by the original author.

TL;DR

Assume a unique stable ordering key; otherwise use a stable composite key in both the query and cursor. Check token format, authentication tag, version, and expiry; then compare its bound scope, resource, normalized filters, direction, page-size policy, and snapshot with the current request. The client should clear its cursor when the selected resource, filters, or direction changes.

When to use

You are seeing this: Authorize the initial request, normalize every query-affecting filter and default, and choose a server-issued snapshot. Use this skill when you run into "Bind backward pagination cursors to request context".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Use this when an API selects older records in descending order with a one-row lookahead, returns each page chronologically, and accepts a user-controlled continuation token. Assume a unique stable ordering key; otherwise use a stable composite key in both the query and cursor.

Preserve the page boundary

Fetch the requested page size plus one in descending order. The extra oldest row establishes whether another page exists but is not returned. Reverse the retained rows for presentation. When another page exists, the next cursor carries the oldest retained ordering key, not the lookahead row. The following query uses a strict older-than predicate.

Issue an opaque authenticated cursor

Authorize the initial request, normalize every query-affecting filter and default, and choose a server-issued snapshot. Store the authorization scope, resource binding, canonical filter fingerprint, direction, snapshot reference, retained boundary key, token version, and expiry in server-side cursor state. Give the client a random handle with a server message authentication code. The handle reveals no internal resource or row identifiers. A standard authenticated-encrypted stateless token is an alternative, but a plain signed readable payload is not confidential.

Bind the page size too if changing it during traversal is disallowed. Sign with a managed key and allow bounded key rotation. Limit token length and lifetime. A token is a continuation hint, never an authorization grant.

Validate before any page query

Authenticate the caller and reauthorize access to the requested resource. Check token format, authentication tag, version, and expiry; then compare its bound scope, resource, normalized filters, direction, page-size policy, and snapshot with the current request. Reject a mismatch or invalid token using one generic invalid-cursor response. Do not echo the token, internal identifiers, or which comparison failed. Do not build a data query from unverified fields.

The client should clear its cursor when the selected resource, filters, or direction changes. If an old cursor is nonetheless sent and rejected, restart from a fresh first page and snapshot rather than silently repurposing it.

Define snapshot semantics explicitly

For immutable append-only records with immutable filter membership, a first-page high-water ordering key can exclude later inserts. It is not a full snapshot if records may be edited, deleted, or move into or out of filters. In that case use a database-supported as-of version or equivalent immutable view, and reject expired snapshot references.

Basis

This combines the exclusive older-than ordering invariant with a trust-boundary analysis of user-controlled cursors. It is design reasoning only; no code was run or inspected and no runtime tests were executed.

Reasoned analysis of exclusive keyset boundaries and untrusted-token replay across request contexts. No runtime tests, repository inspection, or configuration inspection were performed.

Rationale: The prior guidance selected the correct page boundary but did not prevent a valid cursor from being replayed against another resource, filter set, direction, or snapshot. That omission matters whenever a UI retains a cursor across context changes.