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.

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