Action Scheduler 4 includes changes around unique actions. Before retrying failed WooCommerce jobs, prove which arguments make an action unique so payment, email, shipment, CRM, and conversion jobs do not duplicate business events.
Use this for WooCommerce stores with scheduled payment retries, webhook delivery, CRM sync, fulfillment events, subscription renewals, and conversion uploads.
Quick answer
Action Scheduler 4 Unique Args Duplicate Retry Audit should be handled with a narrow evidence-first workflow: export action args, map identities, classify side effects, then verify the result before making broader changes.
What to check first
- Export failed and pending actions with hook, group, args, claim, attempts, and logs.
- Identify which fields make the action safe to retry: order ID, event ID, webhook ID, subscription ID, or lead ID.
- Separate actions that are idempotent from actions that can create duplicate money movement or customer messages.
- Check whether Action Scheduler 4 changes how the extension treats actions with different arguments.
- Retry a tiny controlled sample and confirm the destination system accepts one event.
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 |
|---|
| Export action args | Export failed and pending actions with hook, group, args, claim, attempts, and logs. | Every retried job has a stable order, lead, webhook, subscription, or event ID. |
| Map identities | Identify which fields make the action safe to retry: order ID, event ID, webhook ID, subscription ID, or lead ID. | Payment, email, shipment, and conversion jobs have separate retry rules. |
| Classify side effects | Separate actions that are idempotent from actions that can create duplicate money movement or customer messages. | The destination system shows one accepted event for the sample retry. |
| Patch missing IDs | Check whether Action Scheduler 4 changes how the extension treats actions with different arguments. | The owner receives a list of held jobs that need manual or vendor review. |
Why this usually happens
- A job name can look unique while its arguments are missing the actual business identifier.
- A failed webhook retry can create duplicate CRM rows if the event ID is not stable.
- Payment and subscription actions may need idempotency keys outside WordPress.
- A queue cleanup hides repeated retries unless the team exports evidence first.
Field notes
- Do not use the same retry policy for emails, payments, shipments, and cleanup jobs.
- A good queue report names the destination side effect, not only the WordPress hook.
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 --status=failed --format=json > failed-actions.json
jq '.[] | {action_id,hook,group,args,attempts,status}' failed-actions.json | head
wp action-scheduler logs ACTION_ID
# Mark each hook: idempotent, needs key, hold, safe retry, or vendor review.
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.
- Export action args
- Map identities
- Classify side effects
- Patch missing IDs
- Retry small sample
What to tell the client or owner
Tell the owner which jobs are safe to retry, which are risky, and which system owns deduplication.
Production verification checklist
- Every retried job has a stable order, lead, webhook, subscription, or event ID.
- Payment, email, shipment, and conversion jobs have separate retry rules.
- The destination system shows one accepted event for the sample retry.
- The owner receives a list of held jobs that need manual or vendor review.
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, monitor WooCommerce scheduled jobs safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references