Chunking prevents one large WooCommerce POS catalog job from exhausting a request, but interruption creates a second risk: a worker can resume from a stale cursor while products, prices, or visibility change. The test needs controlled failures and a complete server-to-device reconciliation.
Use this for WooCommerce 11 stores using the POS experience with large catalogs, variable products, frequent price updates, object cache, scheduled workers, mobile devices, and unstable store networks.
Quick answer
Freeze a known catalog revision, interrupt generation after selected chunks, and resume from the stored cursor. Repeat during a product update and device restart. Compare product IDs and checksums between WooCommerce and the device. No revision may report complete with missing, duplicated, or stale records.
What to check first
- Record catalog revision, eligible product count, variation count, chunk size, sort key, cursor, lock owner, expiration, worker ID, device ID, and app version.
- Terminate the worker before write, after write but before acknowledgement, and after acknowledgement but before the next cursor is saved.
- Drop the device connection during chunk download, acknowledgement, local database commit, and final completion response.
- Change a price, stock value, visibility flag, and variation between retries to test revision invalidation.
- Compare authoritative and device product ID sets, checksums, prices, stock, and visibility after each recovery path.
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 |
|---|
| Create a fixed catalog baseline | Record catalog revision, eligible product count, variation count, chunk size, sort key, cursor, lock owner, expiration, worker ID, device ID, and app version. | The resumed chunk checksum matches the original write. |
| Inject failures at durable boundaries | Terminate the worker before write, after write but before acknowledgement, and after acknowledgement but before the next cursor is saved. | No two active workers own the same revision and cursor. |
| Resume with revision-aware tokens | Drop the device connection during chunk download, acknowledgement, local database commit, and final completion response. | A mid-run catalog change produces a clean new revision. |
| Invalidate mixed-revision work | Change a price, stock value, visibility flag, and variation between retries to test revision invalidation. | Server and device ID, price, stock, and visibility sets match. |
Why this usually happens
- A cursor can advance before its chunk is durably committed.
- An expired lock can let two workers generate the same chunk.
- Catalog edits can make earlier and later chunks belong to different revisions.
- A device may acknowledge download before its local database transaction commits.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
catalog_revision: r184
chunk_id: 0002
cursor_before: product_004999
failure_point: after_object_write_before_ack
resume_attempt: 1
chunk_checksum_match: true
missing_product_ids: []
duplicate_product_ids: []
device_revision: r184
result: pass
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.
- Create a fixed catalog baseline
- Inject failures at durable boundaries
- Resume with revision-aware tokens
- Invalidate mixed-revision work
- Reconcile device IDs and checksums
Decision rule
Pass only when every interruption either resumes the same revision exactly once or invalidates it and rebuilds cleanly, with no missing, duplicate, stale, or hidden products on the device.
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
- The resumed chunk checksum matches the original write.
- No two active workers own the same revision and cursor.
- A mid-run catalog change produces a clean new revision.
- Server and device ID, price, stock, and visibility sets match.
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, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Is completing all chunks enough proof?
No. Completion can be recorded while the device misses a local commit or while chunks mix revisions. Reconcile actual IDs and checksums.
Should a catalog edit always restart generation?
The implementation may support incremental behavior, but it must define revision semantics and prove a device never receives a mixed snapshot.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, test WooCommerce POS catalog recovery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references