All packsOffline Sync EngineSolve
idempotent sync push replay duplicate message
Replaying the same push message twice should be a no-op, for free
Retrying a push after a timeout is only safe if replaying the same message twice does nothing extra -- the pack gets this from HLC equality, not a dedupe table.
What goes wrong
A client that retries a push after a network timeout (not knowing whether the first attempt actually landed) needs replaying the same message to be harmless -- otherwise a retry after an ambiguous failure can double-apply a write, or a naive dedupe mechanism (tracking which message ids were already seen) adds a whole extra table and its own consistency problems to what should be a simple retry.
Why agents get it wrong
Building an explicit dedupe table (message ids, a seen-before check) is the first idea that comes to mind for "don't apply the same thing twice," mirroring how webhook idempotency is usually solved -- it's not obvious without reading the storage model closely that a cell-based, HLC-stamped design can get the same guarantee from comparison logic that already has to exist for conflict resolution, with no extra table required.
What Offline Sync Engine pre-decides
Because a cell write only applies when its HLC is strictly greater than the stored cell's HLC, replaying an already-applied message compares equal on HLC and is a no-op by the same rule that resolves ordinary conflicts -- there's no separate mutation-id tracking or dedupe table anywhere in the design. Any push can be retried blindly, which is exactly the property a client recovering from an ambiguous network failure needs.
Source: ARCHITECTURE.md 'Core model: a synced cell store'