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.

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