A WooCommerce deployment can update web containers while cron pods, CLI runners, long-lived queue consumers, restore images, or alternate origins keep older plugin code. Action Scheduler may then execute checkout follow-ups, emails, webhooks, imports, analytics cleanup, or log maintenance under a different WooCommerce version from the request that created the action. That creates hard-to-reproduce partial regressions.
Use this for containerized, autoscaled, blue-green, multisite, managed-host, and high-volume WooCommerce deployments with separate cron or Action Scheduler workers.
Quick answer
Attach runtime identity, image digest, WordPress version, WooCommerce version, package hash, hook, claim ID, action ID, start time, and result to worker diagnostics. During deployment, stop stale claim acquisition, drain or expire claims according to policy, replace workers from the canonical image, and run harmless fixtures for orders, email, webhooks, imports, and cleanup. Alert when any active worker differs from the approved package hash.
What to check first
- List web, cron, CLI, Action Scheduler, queue, webhook, import, analytics, and cleanup runtimes.
- Collect image digest, package hash, WooCommerce version, deployment time, process start, last heartbeat, claim, hook, and owner.
- Map each scheduled hook to its business effect, idempotency behavior, retry policy, and safe fixture.
- Check deployment, autoscaling, rollback, backup, and restore definitions for stale worker images.
- Observe pending, in-progress, failed, canceled, and overdue actions before and after worker replacement.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build web and worker runtimes from the same approved WooCommerce package source. | List web, cron, CLI, Action Scheduler, queue, webhook, import, analytics, and cleanup runtimes. | All active workers report the approved package and image digest. |
| Gate claim acquisition during deployment and handle in-progress actions by hook policy. | Collect image digest, package hash, WooCommerce version, deployment time, process start, last heartbeat, claim, hook, and owner. | In-progress claims complete or retry exactly according to hook policy. |
| Replace stale workers and update autoscaling, rollback, restore, and cron definitions. | Map each scheduled hook to its business effect, idempotency behavior, retry policy, and safe fixture. | No order, email, webhook, import, or cleanup fixture produces duplicate effects. |
| Run idempotent order, email, webhook, import, and cleanup fixtures on the new workers. | Check deployment, autoscaling, rollback, backup, and restore definitions for stale worker images. | Autoscaling and restore tests start patched before claiming work. |
Why this usually happens
- Web and worker services often use separate deployment definitions or schedules.
- A long-lived process keeps loaded PHP code even after files on shared storage change.
- Rollback and autoscaling references can reintroduce an older image after the primary rollout appears complete.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
runtime,role,image,woo,package,claim,hook,state
web-a,checkout,sha256:b11,11.0.1,8ca1,,request,pass
worker-a,actions,sha256:b11,11.0.1,8ca1,c-81,send_email,pass
worker-b,actions,sha256:9d2,11.0.0,72fe,c-82,webhook,replace
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal deploy | Drain then replace worker | New claims use approved package |
| Long action | Claim spans deployment | One completion or controlled retry |
| Stale scale-out | Old template tries to start | Health gate rejects worker |
| Restore | Backup starts isolated | Patch gate runs before claims |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Build web and worker runtimes from the same approved WooCommerce package source.
- Gate claim acquisition during deployment and handle in-progress actions by hook policy.
- Replace stale workers and update autoscaling, rollback, restore, and cron definitions.
- Run idempotent order, email, webhook, import, and cleanup fixtures on the new workers.
- Alert on active runtime, package, image, claim-age, failure-rate, or queue-lag drift.
Decision rule
Parity is complete only when every runtime capable of claiming WooCommerce work runs the approved package and a stale image cannot return through scale-out, rollback, or restore automation.
Production verification checklist
- All active workers report the approved package and image digest.
- In-progress claims complete or retry exactly according to hook policy.
- No order, email, webhook, import, or cleanup fixture produces duplicate effects.
- Autoscaling and restore tests start patched before claiming work.
Field notes
- Do not cancel revenue-critical actions in bulk without hook-specific recovery plans.
- Protect diagnostic endpoints that reveal package versions and image identities.
- Use stable action IDs to distinguish retries from duplicate business outcomes.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, browser behavior, cache, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email route, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WooCommerce background workers.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Drain old claims before resuming new workers
Use the WooCommerce Action Scheduler claim-drain deployment test to gate new claims, finish or release active work, replace workers, resume pending actions, and reconcile each business outcome once.
Alert on the oldest customer-impacting action
Add the WooCommerce Action Scheduler oldest-action SLO to classify hook age, claims, retries, deployment drains, error-budget burn, and one reconciled business outcome.
Helpful references