WooCommerce 11.0 surfaces failed historical Analytics imports and a retry path. A retry can report success while the failed job remains queued, an old batch continues running, progress points at the wrong generation, duplicate rows appear, or totals mix data from overlapping imports.
Use this for WooCommerce store operators, finance, analytics engineers, agencies, and support teams recovering historical Analytics imports.
Quick answer
Freeze the failed import ID, generation, date range, batch size, status endpoint response, failed actions, queue claims, progress, and report totals before retry. Start one controlled retry. Join old and new job IDs, batch keys, row identities, attempts, claims, completion, and cancellation. Reconcile source orders, refunds, taxes, discounts, gross, net, and date buckets. Remove an orphan only after proving it cannot own valid unfinished work.
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 |
|---|
| Single failed batch | One controlled retry | Old job closes and new batch owns work |
| Worker interruption | Retry stops mid-generation | Progress resumes without duplicate rows |
| Overlapping retry | Operator clicks twice | Second request is rejected or deduplicated |
| Timezone edge | Order and refund near midnight | Correct bucket and reconciled net sales |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze failed-generation, action, progress, and source-cohort evidence. | Record WooCommerce, database, HPOS, Analytics, Action Scheduler, extensions, timezone, and import settings. | Status endpoint, queue actions, generation, and progress describe the same work. |
| Retry once with stable row and batch idempotency keys. | Preserve the failed import response, date range, generation ID, batch boundaries, progress, action IDs, errors, attempts, and claims. | Every source order and refund maps to one expected Analytics row. |
| Stop or quarantine confirmed orphan work before it can write again. | Trigger one retry and map every old and new job, batch key, row identity, schedule, claim, completion, cancellation, and exception. | No failed, claimed, pending, or orphaned action can mutate the completed cohort. |
| Rebuild or repair only the affected date and row cohort. | Compare source orders and refunds to Analytics rows by stable order and date-bucket keys, including store timezone and UTC boundaries. | Gross, refunds, tax, discounts, net, and date buckets reconcile to the source. |
What to check first
- Record WooCommerce, database, HPOS, Analytics, Action Scheduler, extensions, timezone, and import settings.
- Preserve the failed import response, date range, generation ID, batch boundaries, progress, action IDs, errors, attempts, and claims.
- Trigger one retry and map every old and new job, batch key, row identity, schedule, claim, completion, cancellation, and exception.
- Compare source orders and refunds to Analytics rows by stable order and date-bucket keys, including store timezone and UTC boundaries.
- Check for stale progress, duplicate report rows, orphaned scheduled actions, overlapping generations, and a false 100 percent completion state.
Field notes
- Do not delete queue rows from production until ownership is proven.
- Hash the source cohort and result set before comparing totals.
- Keep finance sign-off separate from the technical completed flag.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
generation,job,batch,source_rows,inserted,duplicates,missing,action_state,progress,result
G-41,J-9,B-3,500,492,0,8,failed,68%,retry
G-42,J-14,B-3,500,500,0,0,complete,100%,pass
G-41,J-9,B-4,0,0,0,0,orphaned,68%,review
Why this usually happens
- Retry APIs and background workers can create a new generation while the old one still has scheduled work.
- Progress counters can be cached separately from row insertion.
- Idempotency keys may be batch-specific rather than source-row-specific.
- Report totals can appear plausible even when duplicates and missing rows offset each other.
Decision rule
Call the retry successful only when one generation owns every batch, no old action can write again, source rows appear exactly once, progress matches completed work, and financial totals reconcile.
Production verification checklist
- Status endpoint, queue actions, generation, and progress describe the same work.
- Every source order and refund maps to one expected Analytics row.
- No failed, claimed, pending, or orphaned action can mutate the completed cohort.
- Gross, refunds, tax, discounts, net, and date buckets reconcile to the source.
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.
- Freeze failed-generation, action, progress, and source-cohort evidence.
- Retry once with stable row and batch idempotency keys.
- Stop or quarantine confirmed orphan work before it can write again.
- Rebuild or repair only the affected date and row cohort.
- Reconcile detailed rows and financial totals before closing the import.
Mistakes to avoid
- Changing production before preserving exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, providers, caches, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
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, repair WooCommerce Analytics imports.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Reconcile partial refunds after retry
After orphan work is cleared, use the WooCommerce partial-refund date-bucket reconciliation to prove every refund appears once in the intended period and net sales agree across reports.
Helpful references