A Data Manager request-status worker can pause during a network call, let its lease expire, and return after a replacement worker acquired ownership. Without a monotonically increasing fencing token and conditional writes, the stale worker can overwrite newer backoff, terminal status, or alert state.
Use this for WordPress lead pipelines, WooCommerce conversions, CRM imports, and Google Ads Data Manager uploads that poll request status from multiple cron, queue, or deployment workers and store state in DynamoDB.
Quick answer
Store one item per request ID with lease owner, numeric fencing token, expiry, next poll, attempt, status, response hash, and terminal version. Acquire with a conditional update that increments the token. Every renew, schedule, and final write must require the same owner and token. Once a newer token exists, the old worker must become a no-op even if its API call succeeded.
What to check first
- List WordPress cron, Action Scheduler, system cron, queue workers, Lambda, deployment recovery, dead-letter replay, and support tools that can poll or finalize the same request.
- Define the DynamoDB key, owner, token, lease expiry, next poll, attempt, backoff, API status, response hash, terminal version, alert ID, created time, updated time, and cleanup TTL.
- Acquire with a conditional expression for missing or expired ownership, atomically increment the fencing token, and return the new token to the worker.
- Require owner plus token for renewal, next-poll scheduling, API result writes, terminal transition, business retry decision, and alert creation so stale workers cannot commit.
- Test simultaneous acquire, delayed response beyond expiry, clock skew, crashed worker, replacement owner, duplicate terminal response, rate limit, replay, and TTL cleanup.
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 |
|---|
| Model one request-state item | List WordPress cron, Action Scheduler, system cron, queue workers, Lambda, deployment recovery, dead-letter replay, and support tools that can poll or finalize the same request. | Two simultaneous workers produce one successful acquire and one conditional failure. |
| Acquire with a conditional increment | Define the DynamoDB key, owner, token, lease expiry, next poll, attempt, backoff, API status, response hash, terminal version, alert ID, created time, updated time, and cleanup TTL. | A worker returning after lease expiry cannot update schedule, response, terminal state, or alert with its old token. |
| Fence every worker write | Acquire with a conditional expression for missing or expired ownership, atomically increment the fencing token, and return the new token to the worker. | The current owner renews and finalizes only while owner and token still match. |
| Make terminal transition idempotent | Require owner plus token for renewal, next-poll scheduling, API result writes, terminal transition, business retry decision, and alert creation so stale workers cannot commit. | TTL removes only completed operational records after the audit and replay retention window. |
Why this usually happens
- An expiring lease controls ownership only until a worker pauses longer than expected.
- A stale worker still holds its process memory and can attempt a write after replacement.
- Two cron systems can enqueue the same request before either commits schedule state.
- A terminal response and alert can duplicate when they are not guarded by one versioned state transition.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
aws dynamodb update-item \
--table-name request-status \
--key '{"requestId":{"S":"req-8f23"}}' \
--update-expression 'SET leaseOwner=:owner, leaseExpiresAt=:exp ADD fencingToken :one' \
--condition-expression 'attribute_not_exists(leaseOwner) OR leaseExpiresAt < :now' \
--expression-attribute-values file://lease-values.json \
--return-values ALL_NEW
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.
- Model one request-state item
- Acquire with a conditional increment
- Fence every worker write
- Make terminal transition idempotent
- Stress expiry and replacement
Decision rule
Pass when one token owns the request at a time, every stale token write fails cleanly, terminal state persists once, polling stops, and retries or alerts cannot 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
- Two simultaneous workers produce one successful acquire and one conditional failure.
- A worker returning after lease expiry cannot update schedule, response, terminal state, or alert with its old token.
- The current owner renews and finalizes only while owner and token still match.
- TTL removes only completed operational records after the audit and replay retention window.
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
Why not use only lease expiry?
Expiry allows replacement but does not stop the old worker from writing later. The fencing token rejects stale ownership.
Should the token reset when a request retries?
No. Keep it monotonic for the life of the request-state item so older owners remain distinguishable.
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, build a reliable Data Manager polling pipeline.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references