A POS device may miss several catalog revisions while offline. When it reconnects, queued actions, an incomplete older download, and the newest server snapshot can compete, creating mixed prices, missing products, or stock decisions based on stale local data.
Use this for mobile registers, pop-up locations, event sales, unstable Wi-Fi, overnight devices, or any POS installation that permits offline browsing or queued transactions.
Quick answer
Take a controlled device offline, publish several catalog changes, interrupt one partial sync, and reconnect. The device should select one valid target revision, discard incompatible chunks, apply it atomically, and block or warn on checkout until required price and stock data is current.
What to check first
- Record the device revision, pending local actions, partial chunk manifest, app version, clock offset, and network state before disconnecting.
- While offline, publish product add, delete, price, stock, tax, variation, and visibility changes across at least two revisions.
- Reconnect once on a slow network and once after terminating the app during the transfer.
- Verify how queued offline transactions are ordered relative to catalog refresh and stock reconciliation.
- Check whether checkout is blocked, warned, or safely permitted while the target revision is incomplete.
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 |
|---|
| Capture the offline starting state | Record the device revision, pending local actions, partial chunk manifest, app version, clock offset, and network state before disconnecting. | The rejoined device reports the current revision and checksum. |
| Publish a controlled revision sequence | While offline, publish product add, delete, price, stock, tax, variation, and visibility changes across at least two revisions. | No old partial chunks remain active after apply. |
| Interrupt and resume the transfer | Reconnect once on a slow network and once after terminating the app during the transfer. | Queued sales and stock changes reconcile exactly once. |
| Order queued writes and catalog apply | Verify how queued offline transactions are ordered relative to catalog refresh and stock reconciliation. | Price, tax, variation, visibility, and stock canaries match before normal checkout resumes. |
Why this usually happens
- Partial chunks from an older revision may remain in local storage.
- Offline transactions and catalog refresh can replay in the wrong order.
- A device clock can mislead age-based checks.
- Checkout may read local data before the atomic catalog apply completes.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
device_id: pos-event-02
offline_revision: 180
server_revision: 184
partial_manifest: revision-182-chunks-1-18
queued_sales: 4
rejoin_target: 184
stale_chunks_discarded: true
checkout_blocked_until_apply: true
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.
- Capture the offline starting state
- Publish a controlled revision sequence
- Interrupt and resume the transfer
- Order queued writes and catalog apply
- Verify checkout on the final revision
Decision rule
Pass when the device applies one complete current revision, incompatible chunks are discarded, queued sales reconcile once, and checkout cannot silently use a mixture of stale and current catalog data.
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 rejoined device reports the current revision and checksum.
- No old partial chunks remain active after apply.
- Queued sales and stock changes reconcile exactly once.
- Price, tax, variation, visibility, and stock canaries match before normal checkout resumes.
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
Can the device apply only the revisions it missed?
It can if the protocol guarantees an ordered compatible chain. A full snapshot is safer when an interrupted chain or schema change makes incremental replay ambiguous.
What should happen to offline sales during rejoin?
They need a documented ordering and conflict policy. Preserve each transaction ID, apply once, and surface stock or price conflicts to an operator.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, 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, test WooCommerce POS offline recovery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references