The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. Last-write-wins depends on comparable clocks and silently loses concurrent intent. A vector causally dominates only when every component is at least as high.
Distributed correctness comes from idempotency keys, leases, monotonic versions, and reconcilable facts—not an assumption of one delivery. A timeout means unknown outcome, not confirmed failure.
Make the implementation decisions explicit
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Use vectors only for genuine multi-writer offline entities; merge fields by union, revocation-wins, or explicit choice, and compact retired device components.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Treat cleanup as protocol behavior: timers, handles, queues, and temporary data must be safely releasable in every terminal state.
The delivery standard for When Version Vectors Beat Last-Write-Wins for Peer State is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Object-wide LWW lets a later nickname update resurrect revoked trust, while retaining every device component grows metadata forever.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- Ideal-size tests miss large files, long sessions, and concurrency that cross hidden limits and cause cascading failure.
How to verify it before release
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Make two offline devices revoke trust and edit settings, then vary delivery order and repeat merges; the result must be deterministic, idempotent, and never revive security state.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.