Offline Queue Reconciliation After a 26-Hour Outage

The log message means the sync wrote some local changes but did not resolve divergent versions of the same logical record. The nine duplicates are probably two revisions of one work order, not nine new work orders, because each pair has a different modification timestamp but shares a work-order identity. The three missing edits suggest the local outbox was not fully flushed or the server applied a last-writer-wins rule and overwrote them.

Before changing anything, compare four things:

1. Record identity - the server work-order ID versus the local record ID, not just the description or asset name.
2. Revision evidence - device sequence number, server revision number, and audit-log entry for each copy.
3. Field-level values - measurements, status, notes, and user ID. A duplicate is not automatically the disposable copy; one may contain the only valid reading.
4. Queue state - the local outbox and sync log, to see whether the three missing edits still exist locally and were simply not acknowledged.

The clock being within 40 seconds rules out major clock skew as the main cause. The storage jump from 78% to 91% is more suspicious: a nearly full queue can truncate or fail to commit records. The technician should not delete duplicates until the audit trail has been exported, because deletion destroys the evidence needed to reconstruct the missing edits.

A defensible procedure is conservative and auditable:

1. Freeze further edits and automatic sync if the device allows it. Continued syncing can create more versions while the technician is investigating.
2. Export the sync log and local audit trail to a file or capture them with the device's export function. Record the export time and device ID.
3. Handle the three missing edits first, because they are known losses. Search the local outbox, draft area, and journal for the original entries. If the edits are replayable, resubmit them with the original timestamps and a note that they are recovered offline changes. If they are not recoverable, mark the three work orders as "verification required" and schedule re-measurement; do not invent values from memory.
4. Resolve each duplicate pair by field-level merge, not by deleting one copy. Choose the canonical server ID, compare measurement, status, notes, and user, and keep the correct value for each field. If two measurements conflict and neither can be proved correct, flag the record for re-measurement.
5. Document every merge with the reason, the source revision, and the technician's identity.
6. Verify the final count: 1,240 original records plus 12 new records should equal 1,252 logical work orders, with no unexplained duplicate IDs.

With 30 minutes, the technician should not attempt a full manual re-entry. The priority is to prevent data loss, preserve evidence, and flag uncertain records rather than close the shift with false confidence.

Two changes address the two observed failure modes:

1. Enable conflict detection with revision tracking. The device should attach a revision number or version vector to every offline edit and refuse to merge silently when the server copy has changed. The sync result should list each conflict by record ID, not end with a generic "partial conflict." This would have made the nine duplicate pairs visible before they were written as separate records.
2. Add a storage and sync-health guard. Set a warning at 80% and a hard block on new offline edits at 90% unless the technician archives or uploads. Before an outage, the device should warn that the cache is near capacity and that the outbox contains unacknowledged changes. This addresses the 78% to 91% jump and the risk that the local queue was truncated.

A useful third control is a pre-outage checklist that confirms the device has synced, the battery is sufficient, and the local queue is empty. The key point is that the device must make conflicts and capacity limits explicit; a technician under time pressure cannot be expected to detect silent overwrites from a generic log message.