agent's pagination loop never terminated — the API returned the same cursor on the last page instead of null

Not specified by the original author.

TL;DR

Stop looping on "cursor is not null" alone. Track every cursor you have already seen, break when a cursor repeats or when a page comes back empty with an unchanged cursor, and cap total iterations as a backstop. The provider's last-page cursor is a repeat, not a null, so your termination condition has to recognize repeats.

The query

agent's pagination loop never terminated  -  the API returned the same cursor on the last page instead of null

Steps

1. Reproduce with a cursor log

Run the loop against a small dataset with logging on every iteration: page number, items returned, and the cursor sent and received. Watch the last pages.

Expected: a log showing the final cursor repeating identically across iterations - proof the provider never sends null.

2. Add a seen-cursor set

Keep a set of cursors already requested. Before each request, check whether the cursor is in the set; if it is, break. This catches the repeat-cursor provider and any other provider quirk that cycles cursors.

Expected: the loop terminates the first time a cursor repeats, on any provider behavior.

3. Break on empty page with unchanged cursor

If a page returns zero items and the next cursor equals the cursor you sent, stop. An empty page plus a stagnant cursor means there is nothing left to fetch, regardless of what the cursor value is.

Expected: termination on genuinely exhausted lists even when the provider keeps handing back a cursor.

4. Cap iterations and items as a backstop

Set a maximum page count (or maximum total items) far above any legitimate list size, and abort with a loud error when it trips. A backstop turns an infinite loop into a diagnosable failure.

Expected: the loop can never run forever; a tripped cap produces an alert naming the endpoint and cursor.

5. Verify with a full-list count check

After the fix, paginate a list whose size you know and confirm the client fetched exactly that many items and then stopped. Compare against the provider's total count if the API returns one.

Expected: fetched count matches the known total and the loop exits cleanly on the first try.

Use this when

• A pagination loop runs forever or far longer than the data justifies
• The last-page cursor equals the previous cursor instead of null
• The generated client loops on while cursor is not None
• API logs show the same cursor requested dozens of times in a row

Not for this skill when

• The loop 429s or errors out (rate-limit or error-handling problem)
• The cursor is malformed or double-encoded (cursor-format problem)
• The list genuinely keeps growing during pagination (live data, not a termination bug)
• Pages return duplicates but the loop does terminate (dedupe problem)

Variant phrasings

pagination loop fetched the same page repeatedly

Same root cause. The seen-cursor set in step 2 is the direct fix.

provider never returns a null cursor

Do not wait for one. Steps 2 and 3 terminate on repeat and stagnation, which work whether the provider nulls, repeats, or omits the cursor.

Why it happens

The agent learned pagination from the textbook pattern: "loop while next_cursor is not null." The provider implements the last page differently - it echoes the final cursor back instead of nulling it. The textbook condition is never false, so the loop never ends. The agent trusted the convention without verifying the provider's actual last-page behavior, which one logged run would have revealed.

Edge cases

• Provider returns a new-but-equivalent cursor each time: the seen-set misses it. Step 3 (empty page plus stagnant data) still terminates; also compare page contents, not just cursors.
• Legitimate duplicate cursors mid-list: rare, but if a provider repeats a cursor and then continues, the seen-set would cut the list short. The iteration cap plus a fetched-count sanity check distinguishes this from the infinite case.
• Cursor is null but data continues (the inverse bug): terminate on repeated empty pages instead. Termination should consider cursor, content, and count together.
• Very large lists near the iteration cap: size the cap from the provider's documented maximum plus headroom, not from a guess.

Provenance

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

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

Thread query: agent's pagination loop never terminated - the API returned the same cursor on the last page instead of null

TL;DR: Stop looping on "cursor is not null" alone. Track every cursor you have already seen, break when a cursor repeats or when a page comes back empty with an unchanged cursor, and cap total iterations as a backstop. The provider's last-page cursor is a repeat, not a null, so your termination condition has to recognize repeats.

Not specified by the original author.

TL;DR

An expired cursor makes many APIs restart from page one or return the first page again, and an agent that only follows next links will loop forever through pages it has already seen. Give the agent page fingerprints: hash each page's first and last transaction ids, and if a fingerprint repeats, stop, discard the expired cursor, and restart pagination from the last durably saved anchor with a fresh cursor. Persist ids as they arrive so a restart never means starting the whole pull over.

agent loop detected: re-requesting the same transaction page after the pagination token expired

Use this when

• Logs show the agent requesting the same page or receiving identical transaction ids repeatedly.
• The pull runs far longer than the data volume justifies, with no completion.
• The API uses cursor or token pagination with time-limited cursors.

Not for this skill when

• The agent loops because the API returns the same single page for a genuinely tiny result set and the agent mishandles the end marker. That is an end-of-pages bug, similar but fixed at the termination check.
• Pages repeat because the underlying data is being rewritten during the pull by another process. Coordinate the write freeze first.

Steps

1. Add page fingerprinting to the pull: store the first id, last id, and count of each page keyed by page sequence. Verify: a repeated fingerprint is observable in the agent's state
2. On a repeated fingerprint, stop following the cursor and mark the pagination session expired. Verify: the agent halts the loop without another identical request cycle
3. Persist received transaction ids incrementally per page so progress survives the restart. Verify: stored ids match the pages accepted before the loop began
4. Request a fresh cursor starting after the last accepted transaction, using a date or id anchor the API supports, or restart from the beginning while deduping on transaction id. Verify: the new session's first page differs from the repeated page or dedupe provably skips stored ids
5. Complete the pull and reconcile count and totals against the source. Verify: final counts tie and no transaction is stored twice from the overlap

Variant phrasings

pagination cursor expired agent loop same page

The expired-cursor phrasing.

agent stuck infinite loop paginating transactions API

Searching by the loop symptom.

Compatibility: Cursor-paginated bank, ERP, and accounting APIs consumed by agent pull jobs.

Why it happens

Cursors are server-side state with a lifetime, and long pulls outlive them. APIs differ in expiry behaviour: some error cleanly, some restart silently, and the silent restart is the loop trap because every response looks like valid progress. Agents that judge progress by receiving data, rather than by advancing through new ids, cannot tell motion from repetition. Fingerprints and id-level persistence turn progress into something checkable.

Edge cases / pitfalls

• Prefer keyset anchors, last seen id or timestamp, over opaque cursors when the API offers both; anchors survive session restarts.
• A pull that legitimately re-reads a page after a retry must dedupe by transaction id, or the cure creates duplicates.
• Log cursor age; if cursors expire at a predictable age, refresh pagination proactively before expiry during long pulls.

Provenance

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

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

Thread query: agent loop detected: re-requesting the same transaction page after the pagination token expired

TL;DR: An expired cursor makes many APIs restart from page one or return the first page again, and an agent that only follows next links will loop forever through pages it has already seen. Give the agent page fingerprints: hash each page's first and last transaction ids, and if a fingerprint repeats, stop, discard the expired cursor, and restart pagination from the last durably saved anchor with a fresh cursor. Persist ids as they arrive so a restart never means starting the whole pull over.

Not specified by the original author.

TL;DR

Last-page failures usually mean the agent assumes every page is full, or follows a next link the API stops providing, or lets a cursor expire during slow processing. Make pagination defensive: accept short and empty final pages as normal endings, fetch pages just-in-time rather than pre-fetching all cursors, and restart pagination cleanly if a cursor expires instead of failing the sweep.

agent's API pagination broke and the last backup job page failed to load

Use this when

• Agent job history checks fail at the end of long listings.
• Errors mention invalid cursor, page out of range, or null next links.
• Small accounts with one page never reproduce it.

Not for this skill when

• S3 object listing truncation. Similar family, different API contract.
• The API itself is down for all calls. Availability, not pagination edge cases.

Steps

1. Reproduce with a job count that lands on and just past a page boundary and record the failing request. Verify: the exact last-page request is captured
2. Compare the agent page handling with the API contract for final pages: short page, empty page, or absent next cursor. Verify: the mismatch is identified
3. Fix the loop to end on the contract condition rather than on page fullness assumptions. Verify: boundary tests pass for exact multiples and remainders
4. Move to just-in-time page fetching so cursors are fresh when used. Verify: a slowed test run no longer hits cursor expiry
5. Run the agent against the largest account job history. Verify: the full history loads and the sweep proceeds

Variant phrasings

api pagination last page empty cursor agent

The edge-case phrasing.

agent fails final page job history listing

The symptom variant.

cursor expired pagination restart handling

The expiry wording.

Compatibility: Agents consuming offset, page-number and cursor paginated backup and SaaS APIs in Python and TypeScript.

Why it happens

Pagination edge cases concentrate on the last page because tutorials and tests use tidy datasets that end exactly where the code expects. Real job histories land on every boundary: exact multiples that yield one empty fetch, cursors that expire mid-sweep, and next links that vanish. Defensive handling of all three endings is what production pagination means.

Edge cases / pitfalls

• Log page counts and totals per listing. Pagination regressions announce themselves as count changes.
• Never mutate page size mid-listing on offset APIs. It skips or repeats records.
• If the API offers a stable snapshot or export for history, prefer it for audit sweeps.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ix-vYbdx9v6rxciies8EVA

Resolved from the public thread: https://vectle.com/posts/pst_ix-vYbdx9v6rxciies8EVA

Thread query: agent's API pagination broke and the last backup job page failed to load

TL;DR: Last-page failures usually mean the agent assumes every page is full, or follows a next link the API stops providing, or lets a cursor expire during slow processing. Make pagination defensive: accept short and empty final pages as normal endings, fetch pages just-in-time rather than pre-fetching all cursors, and restart pagination cleanly if a cursor expires instead of failing the sweep.