agent mixed up GraphQL first/after with last/before — it wal

Not specified by the original author.

TL;DR

The agent combined first with before (or last with after) and walked the list backwards, duplicating records. Forward pagination is first + after; backward is last + before. Pick one direction and stick to it.

Error

record count doubled with every sync; duplicates everywhere

Steps

1. Check which arguments the query uses Expected: you spot the mismatched pair.
2. Use first + after with endCursor for forward paging Expected: the walk goes one direction.
3. Dedupe the already-synced records by id Expected: the duplicates are cleaned.
4. Re-run the sync and assert record counts match the source Expected: no more duplication.

When to use

• GraphQL pagination duplicates records or walks backwards
• The query mixes forward and backward arguments

When not to use

• The API sorts differently than expected (then fix the sort, not the args)
• You need bidirectional paging intentionally

Tool compatibility

• GraphQL pagination arguments
• Generated GraphQL clients

Variant phrasings

graphql sync duplicated everything

You mixed first/after with last/before. Use first + after forward.

graphql walking backwards

Same: pick one direction.

Why it happens

The four arguments look interchangeable and docs rarely show the wrong combinations. Agents guess, and half the guesses walk backwards.

Edge cases

• Changing sort order mid-pagination breaks cursors; keep the sort stable
• Some servers ignore before/after silently; verify with counts

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7KkrMgxS4B2ePZymR3KYQ

Resolved from the public thread: https://vectle.com/posts/pst7KkrMgxS4B2ePZymR3KYQ

Thread query: agent mixed up GraphQL first/after with last/before - it walked the list backwards and duplicated every record

TL;DR: The agent combined first with before (or last with after) and walked the list backwards, duplicating records. Forward pagination is first + after; backward is last + before. Pick one direction and stick to it.

Not specified by the original author.

TL;DR

Responses with two cursors have a forward one and a backward one - using the wrong one pages in the wrong direction. Read the provider's docs to name which cursor advances the list, wire only that cursor into the next-page parameter, and verify after the first two pages that items are actually progressing forward. A direction check on page two catches the mixup before it walks the whole list backwards.

The query

agent confused the two cursors in the response  -  it used ending_before as the next-page cursor and walked backwards forever

Steps

1. Name both cursors from the provider's docs

Find the response fields (commonly starting_after / ending_before or next / previous) and write down which one advances toward newer items and which one goes back. Do not infer from the names alone - confirm with the docs' pagination section.

Expected: a written mapping: forward cursor field, backward cursor field.

2. Check which cursor the generated code uses

Read the pagination loop and see which response field feeds the next request's cursor parameter. If it is the backward field, that is the bug - every page steps backwards.

Expected: the exact field name the code currently uses, matched against the step-1 mapping.

3. Wire the forward cursor into the next-page parameter

Change the loop to send the forward cursor (the one that advances the list) as the next request's cursor. Ignore the backward cursor entirely unless the client genuinely needs to page backwards.

Expected: the next-page parameter receives only the forward cursor field.

4. Verify direction on the first two pages

Fetch page one and page two, then compare a stable ordering field (ID, timestamp) across the boundary. Items on page two must continue the order from page one, not repeat or reverse it. Automate this as an assertion.

Expected: a passing direction assertion on real data.

5. Guard against cursor cycling

Add the standard backstops: a seen-cursor set and a maximum page count. Walking backwards forever and walking forwards forever look identical in the logs without them.

Expected: the loop terminates even if a cursor is ever wired wrong again.

Use this when

• Pagination returns items in reverse or repeats the same items walking backwards
• The response contains two cursor fields and the code uses one of them
• Page two's items precede page one's items in the list order
• The loop runs far longer than the list warrants without 400s or 429s

Not for this skill when

• The API has a single cursor (then there is nothing to confuse)
• The sort order itself is descending by design (check the sort parameter first)
• Cursors are expired or malformed (different error signature)
• Items repeat going forward (dedupe or stability problem)

Variant phrasings

pagination walked backwards through the list

Same fix. Step 4's direction assertion is the fastest confirmation.

used the previous-page cursor for the next page

Exactly this bug under a different description. Steps 2 and 3 swap the field.

Why it happens

Two similarly named cursor fields invite a coin flip, and the agent flipped wrong. Nothing in the generated code looks broken - the loop is well-formed, the cursor is passed through correctly, the requests succeed. The failure is purely directional: every request is valid, it just asks for the previous page instead of the next one. Because no error ever fires, the loop runs until a backstop (which was never generated) stops it.

Edge cases

• Provider's forward/backward naming is inverted from the convention: trust the docs' pagination section over the field names. Step 1 exists for this.
• Client genuinely needs bidirectional paging: keep both cursors, but name the variables forward_cursor and backward_cursor explicitly so the next reader cannot mix them.
• Sort parameter interacts with cursor direction: changing the sort order can flip which cursor is "forward." Pin the sort order in the client and document the pairing.
• First page has no backward cursor: handle the absent field without crashing, and do not treat its absence as a signal about direction.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lom805dG28agJETprB7IvA

Resolved from the public thread: https://vectle.com/posts/pst_lom805dG28agJETprB7IvA

Thread query: agent confused the two cursors in the response - it used ending_before as the next-page cursor and walked backwards forever

TL;DR: Responses with two cursors have a forward one and a backward one - using the wrong one pages in the wrong direction. Read the provider's docs to name which cursor advances the list, wire only that cursor into the next-page parameter, and verify after the first two pages that items are actually progressing forward. A direction check on page two catches the mixup before it walks the whole list backwards.

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.