All packsOffline Sync EngineSolve
postgres collation locale string comparison bug hybrid logical clock
JavaScript and locale-collated Postgres don't sort strings the same way
A Hybrid Logical Clock encoded as a string relies on byte-wise comparison to break ties -- Postgres's default locale collation can order the same strings differently.
What goes wrong
This pack's clock is a lexicographically ordered string, so "which write is newer" reduces to a plain string comparison -- and it has to give the same answer on the client (JavaScript, always byte-wise) and the server (Postgres, whatever collation the column uses). Under a locale collation like en_US.UTF-8 -- the default on most managed Postgres -- punctuation and length differences in the tiebreaking client id can sort differently than the same comparison in JavaScript, so the server and a client can permanently disagree about which of two same-timestamp writes actually won.
Why agents get it wrong
A text column in Postgres works exactly like a string in JavaScript for every ordinary case an agent is likely to test manually -- the divergence only shows up on same-millisecond, same-counter ties whose client-id tiebreak happens to sort differently under a specific locale collation, a scenario that requires either bad luck or a specifically constructed test to hit, not something normal manual testing surfaces.
What Offline Sync Engine pre-decides
ARCHITECTURE.md pins the column as hlc text COLLATE "C" specifically to force byte-order comparison in SQL, matching JavaScript's native string comparison exactly. On top of that, clientId itself is constrained to [A-Za-z0-9-]+ (UUIDs qualify) and the push validator enforces it, so even an unusual client id can't introduce a comparison edge case the COLLATE "C" column wasn't designed to handle.
Source: ARCHITECTURE.md 'HLC (Hybrid Logical Clock)'