The hole in the design as published is the middle state. `syncStatus` takes one of four values [5], and the queue is defined as a live query over two of them, pending and failed [9]. A record that the engine flipped to syncing, on a handset that then lost power or got force-quit, belongs to neither set. Because `syncStatus` is durable data rather than app state [7], it stays syncing through the relaunch, and nothing in the described queue will look at it again. Anyone building this needs a reclaim pass at startup that ages syncing rows back to pending [15], which is another way of saying the queue is at-least-once and some writes will reach the server twice.
So the server contract matters more than the client code. Shah names duplicates as one of the two bugs that will bite [11], and his schema already holds the fix: `serverId` stays null until the server acknowledges the row [5], so the device-minted UUID in `localId` [6] is the only identifier that survives a retry [16]. Replay is safe only if the API deduplicates on that UUID and returns the same `serverId` for a repeat submission rather than inserting a second row. The text supplied stops before saying whether it does [17]. That is the clause to insist on, because it separates a sync engine from a duplicate generator.
The conflict input is `updatedAt`, read from the device clock [5]. Across a field fleet that is the least trustworthy column in the row, and the handset most likely to be carrying a stale clock is the one that spent the day offline in a warehouse, which is also the one whose timestamp decides the merge. Last-write-wins on device time is a defensible policy. It is not a default you get to leave unwritten, because someone will eventually ask which of two visit logs survived and why.
The reason to spend this much on plumbing is the failure mode Shah describes: field users who stop trusting the app go back to paper and WhatsApp [13]. Paper has excellent offline availability. So does a group chat, and neither one reports into your database.
Weigh the evidence for what it is. One practitioner, one post, a React Native platform he says field teams in several countries use daily [2], with no duplicate rate and no count of rows sitting in failed. The examples are Realm and NetInfo, with a claim that the shape ports to WatermelonDB, SQLite or MMKV-backed queues [12]. What you can check without trusting the anecdote is structural: six extra columns on every offline-writable table [14], and a queue that is a query over those columns instead of a second table [9], so it cannot drift out of step with the rows it describes. The price of the pattern is those columns plus one enforced save path [10]. The price of skipping it is a no-internet screen that field teams route around.
