Review request plugins often schedule an email when an order becomes completed, then cancel only for core refund or cancellation statuses. A custom return, chargeback, fraud, or exchange status can leave the action queued even though the customer should no longer receive a review request.
Use this when a store has custom order statuses, sends post-purchase review requests, or has received complaints about review emails after returns or payment disputes.
Quick answer
WooCommerce Review Request Custom Status Cancellation Test should be handled with a narrow evidence-first workflow: map ineligible statuses, schedule test action, trigger each status, then verify the result before making broader changes.
What to check first
- List every status that should make an order ineligible for a review request.
- Create a staging order, schedule the review email, then move it through each custom status.
- Inspect Action Scheduler by order ID, hook, group, scheduled time, and status.
- Confirm the plugin cancels the specific pending action instead of only setting a flag on the order.
- Repeat the transition in both directions to make sure rescheduling does not create duplicates.
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 |
|---|
| Map ineligible statuses | List every status that should make an order ineligible for a review request. | Every ineligible custom status leaves no pending review action for the order. |
| Schedule test action | Create a staging order, schedule the review email, then move it through each custom status. | Eligible completed orders still receive exactly one review request. |
| Trigger each status | Inspect Action Scheduler by order ID, hook, group, scheduled time, and status. | Moving an order out of and back into completed does not create duplicate scheduled actions. |
| Cancel matching row | Confirm the plugin cancels the specific pending action instead of only setting a flag on the order. | The cancellation log records order ID, old status, new status, action ID, and UTC time. |
Why this usually happens
- Plugins can subscribe only to WooCommerce core statuses.
- A custom status slug may include or omit the wc- prefix unexpectedly.
- Changing order metadata does not automatically remove an Action Scheduler row.
- A restored completed status can schedule a second request if no stable action key exists.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp action-scheduler list --search=10822 --fields=action_id,hook,status,scheduled_date_gmt,group
wp wc shop_order get 10822 --fields=id,status,date_modified
# Cancel only the matching pending review action after confirming the plugin hook and arguments.
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.
- Map ineligible statuses
- Schedule test action
- Trigger each status
- Cancel matching row
- Retest rescheduling
What to tell the client or owner
Provide the order ID, custom status slug, review hook, action ID, transition timestamps, cancellation result, and duplicate test result.
Production verification checklist
- Every ineligible custom status leaves no pending review action for the order.
- Eligible completed orders still receive exactly one review request.
- Moving an order out of and back into completed does not create duplicate scheduled actions.
- The cancellation log records order ID, old status, new status, action ID, and UTC time.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, 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, fix WooCommerce review automation.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references