agent failed to page salesforce bulk api: query locator expired mid-export

Not specified by the original author.

TL;DR

Query locators expire after about 15 minutes of inactivity, so a slow consumer loses its place mid-export. Page briskly without long pauses between requests, and if the export is large, use a Bulk API query job instead of the locator pattern. On expiry, re-issue the query; the data is still there.

Error

INVALID_QUERY_LOCATOR: invalid query locator

Steps

1. On expiry, re-issue the original query to get a fresh locator and restart paging from the top, skipping already-processed ids. Expected: the export continues.
2. Remove pauses between page requests: no per-page enrichment, no sleeps, no slow writes. Expected: the locator stays alive.
3. Reduce the page size if each page is slow to transfer, or increase it if round trips dominate. Expected: the sweet spot keeps the locator fed.
4. For exports over a few hundred thousand rows, switch to a Bulk API query job. Expected: no locator to expire.
5. Track processed ids so a restart never double-processes. Expected: idempotent resume.

When to use

• Exports fail with INVALIDQUERYLOCATOR partway.
• An agent enriches each page before fetching the next (too slow).
• Large exports that take longer than 15 minutes.

When not to use

• Bulk API job failures (different mechanics).
• Query syntax errors (fix the SOQL).

Tool compatibility

• Salesforce SOAP and REST query/queryMore with locators.
• Bulk API query jobs as the alternative.

Variant phrasings

invalid query locator

Re-issue and page faster.

queryMore failed mid-export

Same expiry; same fix.

Why it happens

The locator is a server-side cursor with a short idle timeout. Anything that pauses paging (slow processing, rate-limit sleeps, crashes) lets it expire.

Edge cases

• Re-issuing the query can return rows in a different order; dedupe by id.
• Very selective queries re-run fast; unselective full-table queries are slow to restart, favor Bulk API.
• Parallel paging with multiple locators multiplies server load; keep it modest.

Provenance

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

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

Thread query: agent failed to page salesforce bulk api: query locator expired mid-export

TL;DR: Query locators expire after about 15 minutes of inactivity, so a slow consumer loses its place mid-export. Page briskly without long pauses between requests, and if the export is large, use a Bulk API query job instead of the locator pattern. On expiry, re-issue the query; the data is still there.

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.

Not specified by the original author.

TL;DR

Fix this in Salesforce by acting on the exact message first: write back in small confirmed chunks, record the last saved record identifier, refresh the session between chunks, and after any expiry resume the writeback from the unsaved half only. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one record, then rerun the full scope and reconcile the counts.

Session expired mid sync, a Salesforce enrichment writeback saved only half the batch

Use this when

• The operation in Salesforce fails with this exact message: Session expired mid sync, a Salesforce enrichment writeback saved only half the batch.
• The same failure repeats on retry with unchanged inputs.
• A run, import, export or alert is blocked until this item completes.

Not for this skill when

• The message is a permission or platform outage notice. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Salesforce, and copy the full message plus the record, account or list involved into the run notes. Verify: the error is reproduced on demand with a named record, not only seen in a log.
2. Apply the specific fix for this error: write back in small confirmed chunks, record the last saved record identifier, refresh the session between chunks, and after any expiry resume the writeback from the unsaved half only. Verify: one named record now completes end to end with the correct result and the original message does not appear.
3. Check the neighbouring records that share the same source, mapping, workspace or settings, because this class of failure rarely affects only one record. Verify: the neighbouring records are listed and each is marked affected or clear.
4. Compare the result counts, fields or alerts against the source in Salesforce so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in Salesforce on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the record so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

The writeback held the whole batch for one end of run save, so the expiry lost every result that had been enriched but not yet written.

Variant phrasings

Session expired mid sync, a Salesforce enrichment writeback saved only half the batch

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single record proof, then the full rerun.

How to fix this failure in Salesforce

The how to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting this failure in Salesforce

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Salesforce at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: session expired mid-sync Salesforce enrichment writeback half the batch never saved

TL;DR: Fix this in Salesforce by acting on the exact message first: write back in small confirmed chunks, record the last saved record identifier, refresh the session between chunks, and after any expiry resume the writeback from the unsaved half only. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one record, then rerun the full scope and reconcile the counts.