WooCommerce 11 RC 2 testing needs a rollback plan that includes Action Scheduler. Restoring only WordPress tables while web, cron, CLI, or queue workers keep claiming actions can create duplicate emails, stock changes, webhooks, renewals, exports, and payment side effects.
Use this for stores with subscriptions, payment retries, webhooks, email queues, product sync, fulfillment, analytics, or any extension that schedules work through Action Scheduler.
Quick answer
Identify every runner, stop new checkout traffic, pause web cron and CLI workers, wait for active claims to finish or expire, record action table counts, then take the database snapshot. During recovery, keep runners frozen until the old schema and plugin stack are restored, then reconcile all actions created or completed after the snapshot before allowing one controlled worker to resume.
What to check first
- List web requests, WP-Cron, system cron, WP-CLI queue runners, hosting workers, asynchronous requests, and external schedulers that can claim Action Scheduler work.
- Record action IDs, hooks, groups, scheduled dates, statuses, claims, attempts, arguments hashes, related order IDs, and external idempotency keys at the freeze boundary.
- Stop new checkout traffic and runner entry points, then distinguish actions that are pending, in progress, complete locally, or complete only in the external system.
- Restore database and files into an isolated target with cron disabled, verify the expected Action Scheduler schema and plugin versions, and compare restored rows to the freeze ledger.
- Resume one runner with a narrow queue, watch order notes and external systems, replay only proven missing effects, and keep duplicate-effect guards active.
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 queue runner | List web requests, WP-Cron, system cron, WP-CLI queue runners, hosting workers, asynchronous requests, and external schedulers that can claim Action Scheduler work. | Runner logs show no claims after the freeze timestamp. |
| Create a durable freeze ledger | Record action IDs, hooks, groups, scheduled dates, statuses, claims, attempts, arguments hashes, related order IDs, and external idempotency keys at the freeze boundary. | The restored Action Scheduler schema and plugin versions match the rollback plan. |
| Stop claims before the snapshot | Stop new checkout traffic and runner entry points, then distinguish actions that are pending, in progress, complete locally, or complete only in the external system. | Pending, in-progress, complete, failed, and canceled counts reconcile to the freeze ledger. |
| Restore with workers disabled | Restore database and files into an isolated target with cron disabled, verify the expected Action Scheduler schema and plugin versions, and compare restored rows to the freeze ledger. | A duplicate-safe resume processes the selected queue once and leaves no unexplained overdue or failed actions. |
Why this usually happens
- Action claims can be active when a database snapshot begins.
- A worker can commit an external effect before its local completion row is persisted.
- Restoring old rows can make completed work appear pending again.
- Multiple runner types may continue even after one cron mechanism is disabled.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp cron event list --fields=hook,next_run_gmt,recurrence
wp action-scheduler status
wp action-scheduler run --hooks=wc_admin_daily
# During the freeze, record counts by status and do not run queues on the recovery target.
SELECT status, COUNT(*) FROM wp_actionscheduler_actions GROUP BY status;
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 queue runner
- Create a durable freeze ledger
- Stop claims before the snapshot
- Restore with workers disabled
- Reconcile and resume one runner
Decision rule
Pass when no runner can write during restore, each action crossing the snapshot boundary has one owned outcome, external effects are reconciled exactly once, and a controlled resume creates no duplicate stock, email, payment, or fulfillment action.
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
- Runner logs show no claims after the freeze timestamp.
- The restored Action Scheduler schema and plugin versions match the rollback plan.
- Pending, in-progress, complete, failed, and canceled counts reconcile to the freeze ledger.
- A duplicate-safe resume processes the selected queue once and leaves no unexplained overdue or failed actions.
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 disabling WP-Cron enough?
Not if the host, CLI, web requests, or another service can still launch queue runners. Inventory all execution paths.
Can the database restore undo a webhook?
No. Reconcile every external effect with durable provider or destination identifiers.
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, rehearse a WooCommerce queue rollback.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references