agent failed to handle hubspot's paginated search cursor reset

Not specified by the original author.

TL;DR

HubSpot search cursors can reset (results shift as the index updates), sending your pager back to the start or into a loop. Detect repeated cursors or repeated records, restart the search with a stable sort, and dedupe by id. Cursor resets are normal; looping forever is not.

Error

(No error; the symptom is the pager returning records it already returned, or the result set restarting.)

Steps

1. Track seen record ids during paging. Expected: you detect repeats immediately.
2. On repeat detection, stop and restart the search with an explicit stable sort. Expected: deterministic ordering.
3. Dedupe the combined results by id. Expected: each record processed once.
4. If resets persist, narrow the search (tighter filters, smaller time windows) so each search completes before the index shifts. Expected: stable result sets.
5. For full extracts, prefer the list or export APIs over search paging. Expected: no cursor semantics at all.

When to use

• Search paging loops or restarts.
• An agent pages search results and never finishes.
• Result counts that change between pages.

When not to use

• List endpoint pagination (different cursor behavior).
• 429s during paging (rate limits).

Tool compatibility

• HubSpot CRM search API v3 with after cursors.
• Seen-id tracking in the agent.

Variant phrasings

search cursor reset

Restart with stable sort; dedupe.

paging returns duplicates

Same detection, same fix.

Why it happens

Search runs against a live index that updates as you page. Inserts and updates shift result positions, invalidating the cursor's place. The API resets rather than serve wrong pages.

Edge cases

• Sorting by last-modified makes resets more likely; sort by id or created date.
• Very large result sets reset more often; keep searches narrow.
• The after cursor from a reset response may itself be stale; restart clean.

Provenance

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

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

Thread query: agent failed to handle hubspot's paginated search cursor reset

TL;DR: HubSpot search cursors can reset (results shift as the index updates), sending your pager back to the start or into a loop. Detect repeated cursors or repeated records, restart the search with a stable sort, and dedupe by id. Cursor resets are normal; looping forever is not.

Not specified by the original author.

TL;DR

Large exports fail when the pager mishandles the after cursor: reusing a stale cursor, changing sort mid-run, or requesting giant pages. Keep the sort stable, pass the returned after cursor verbatim into the next request, and persist the cursor so a crash resumes instead of restarting.

Error

(No error; the symptom is an export that stalls, repeats records, or dies partway with no clear failure.)

Steps

1. Set a stable sort (by id or created date) and a moderate page size (100). Expected: deterministic pages.
2. Loop: request a page, process it, take the paging.next.after value, and pass it as after on the next request. Expected: steady forward progress.
3. Persist the after cursor after each page (file or database). Expected: a crash resumes from the last cursor.
4. If records repeat or skip, check that nothing changed the sort or filters mid-run. Expected: a stable query produces no gaps.
5. For very large exports, prefer the exports API (async file) over manual paging. Expected: HubSpot builds the file server-side.

When to use

• Contact exports stall or loop on large lists.
• An agent pages the contacts endpoint and never finishes.
• After cursor errors or repeated pages.

When not to use

• Search API cursor resets (different endpoint behavior).
• 429s during paging (rate limits, different fix).

Tool compatibility

• HubSpot CRM API v3 list endpoints with cursor pagination.
• The async exports API for bulk extracts.

Variant phrasings

export stalls partway

Persist the cursor and resume; check sort stability.

paging returns the same page

Stale or mishandled after cursor.

Why it happens

Cursor pagination assumes a stable query. Agents that rebuild the request each iteration, or that lose the cursor on retry, break the chain and either loop or skip.

Edge cases

• Records created during the export can shift pages; export during quiet hours or accept the drift.
• The after cursor expires if unused for a long time; do not pause the loop for hours.
• Filtering on frequently-updated properties makes pages unstable; filter on stable fields.

Provenance

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

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

Thread query: hubspot api pagination failed on large contact export

TL;DR: Large exports fail when the pager mishandles the after cursor: reusing a stale cursor, changing sort mid-run, or requesting giant pages. Keep the sort stable, pass the returned after cursor verbatim into the next request, and persist the cursor so a crash resumes instead of restarting.

Not specified by the original author.

TL;DR

Pagination bugs are silent because page one always works. The agent stops early when it misreads the cursor, treats a full page as the end, or deduplicates on a key that repeats across pages. Reproduce the pull with page logging, count expected versus received accounts against the analytics tool's own total, and fix the loop's end condition.

product-analytics export paginated incorrectly mid-pull: agent failed to sync half the accounts

Use this when

• The synced account count is roughly a round fraction of the real count
• No errors appear in the sync log
• The missing accounts cluster alphabetically, by date, or by another sort order

Not for this skill when

• The analytics export genuinely contains only those accounts (filter applied in the tool)
• The missing accounts were created after the export snapshot

Steps

1. Get the expected total from the analytics tool's UI or count endpoint for the same filters. Verify: the target count is known before touching the agent
2. Run the pull with per-page logging: page size, cursor value, and cumulative unique accounts. Verify: the page where progress stalls or repeats is visible
3. Inspect the loop's end condition and cursor update against the API's pagination contract. Verify: the exact pagination mistake is identified
4. Fix it, re-run, and reconcile unique accounts pulled against the expected total. Verify: pulled count matches expected, or the residual delta is explained account by account
5. Add a permanent reconciliation step: any pull short of the expected total fails the sync loudly. Verify: silent truncation cannot recur

Variant phrasings

analytics export syncs half the accounts

A related phrasing for the same underlying problem.

pagination cursor bug in agent pull

A related phrasing for the same underlying problem.

export truncated silently

A related phrasing for the same underlying problem.

Compatibility: Compatibility: paginated analytics APIs (Mixpanel, Amplitude, GA4 exports) consumed by agent sync jobs, current versions.

Why it happens

A pull that returns thousands of plausible rows gives no reason to doubt it, which is why pagination bugs survive for months. Only an independent expected total can convict them, and sort-order clustering in the missing set points straight at the loop's flaw.

Edge cases / pitfalls

• Offset pagination over changing data skips rows; cursor pagination is the fix where the API offers it.
• Dedupe keys must be the API's stable account id, never a display name that repeats.
• Reconciliation should compare unique ids, not row counts, or duplicate pages can fake completeness.

Provenance

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

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

Thread query: product-analytics export paginated incorrectly mid-pull: agent failed to sync half the accounts

TL;DR: Pagination bugs are silent because page one always works. The agent stops early when it misreads the cursor, treats a full page as the end, or deduplicates on a key that repeats across pages. Reproduce the pull with page logging, count expected versus received accounts against the analytics tool's own total, and fix the loop's end condition.