Data Manager API send calls can return a request ID that must be polled. If cron, queue retries, deployments, or overlapping schedulers create two owners, both can call requestStatus.retrieve, exceed intended rates, reset backoff, write conflicting terminal states, or emit duplicate alerts and retries.
Use this for WordPress lead pipelines, WooCommerce conversions, CRM imports, and server-side Google Ads uploads that store Data Manager request IDs and poll status asynchronously.
Quick answer
Store one durable lease per request ID with owner, fencing token, expiry, next poll time, attempt, and last response hash. Acquire it conditionally, extend only with the same fencing token, and let only the current token write schedule or terminal state. Monitor overlapping owners, polls before next_poll_at, stale leases, high attempts, rate limits, and duplicate terminal alerts.
What to check first
- Map every scheduler that can enqueue or execute a poll, including WordPress cron, Action Scheduler, system cron, queue workers, deployment recovery, dead-letter replay, and manual support tools.
- Store request ID, source batch ID, lease owner, fencing token, acquired time, lease expiry, next poll time, attempt, backoff, last HTTP code, status, response hash, terminal time, and alert ID.
- Acquire and renew the lease with a conditional write so an expired worker cannot overwrite a newer owner's schedule or terminal result after a long network call.
- Use capped exponential backoff with jitter, honor server errors and rate limits, stop immediately at a documented terminal state, and escalate requests that exceed the operational SLA.
- Create dashboards and alerts for concurrent owners, token mismatch writes, early polls, stale leases, request age, high attempts, rate-limit responses, duplicate terminal writes, and duplicate business retries.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory every poll scheduler | Map every scheduler that can enqueue or execute a poll, including WordPress cron, Action Scheduler, system cron, queue workers, deployment recovery, dead-letter replay, and manual support tools. | Starting two workers produces one lease winner and one clean no-op. |
| Persist a fenced request lease | Store request ID, source batch ID, lease owner, fencing token, acquired time, lease expiry, next poll time, attempt, backoff, last HTTP code, status, response hash, terminal time, and alert ID. | A worker whose lease expires during a delayed response cannot update the request after a new token is issued. |
| Enforce backoff and terminal stop | Acquire and renew the lease with a conditional write so an expired worker cannot overwrite a newer owner's schedule or terminal result after a long network call. | Polling stops at terminal state and does not resume after deployment, replay, or cron overlap. |
| Make final writes idempotent | Use capped exponential backoff with jitter, honor server errors and rate limits, stop immediately at a documented terminal state, and escalate requests that exceed the operational SLA. | The monitor detects overlap, early polls, stale age, rate limits, and duplicate finalization with request-safe evidence. |
Why this usually happens
- A scheduler can enqueue the same request before the first job commits its next run time.
- A worker can pause during a network call while its lease expires and a replacement begins.
- Deployment recovery can replay an in-flight message without knowing the prior worker completed.
- A terminal status can be written twice when state and alert delivery are not one idempotent operation.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
request_id: req-8f23
lease_owner: poller-b
fencing_token: 4812
lease_expires_at: 2026-07-30T11:43:00Z
next_poll_at: 2026-07-30T11:44:20Z
attempt: 7
api_status: PROCESSING
last_response_hash: sha256:9da1
terminal_alert_id: null
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory every poll scheduler
- Persist a fenced request lease
- Enforce backoff and terminal stop
- Make final writes idempotent
- Alert on duplicate ownership
Decision rule
Pass when one fencing token owns each request at a time, stale workers cannot write, polls respect stored schedules and rate limits, terminal state is persisted once, and retries or alerts cannot create duplicate conversion effects.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Starting two workers produces one lease winner and one clean no-op.
- A worker whose lease expires during a delayed response cannot update the request after a new token is issued.
- Polling stops at terminal state and does not resume after deployment, replay, or cron overlap.
- The monitor detects overlap, early polls, stale age, rate limits, and duplicate finalization with request-safe evidence.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Is a database lock enough?
A short transaction lock does not protect a long network call. Use an expiring lease with a monotonic fencing token.
Should every non-success status retry the source events?
No. Separate request polling from business retry decisions and use per-destination diagnostics.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, stabilize a Data Manager API polling pipeline.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Fence stale Data Manager polling workers
An expiring lease alone cannot stop a late worker from writing. Use the Data Manager API lease fencing token guide to increment ownership and reject stale DynamoDB writes with a conditional expression.
Helpful references