mirror of
https://github.com/yattee/yattee.git
synced 2026-10-23 13:12:53 +00:00
5abd314c88
A repair is a fallback, not a choice: it borrows the timestamp of the selection it replaced so that a later choice still beats it, and it is never published. But that borrowed rank also won arguments it had no business winning. An incoming explicit context stamped at the same instant that loses the `DataContext.tieBreakKey` tie was neither adopted — the repair was not outranked — nor pushed back, because a repair pushes nothing. Neither side moved, and the fallback stood against the server's explicit value indefinitely. The tie is not theoretical: migrated contexts are all stamped at the epoch, and a repair keeps the timestamp of whatever it replaced, so two migrated-era values meet as equals. A stored repair now never outranks an incoming context — it is replaced by whatever arrived, older or tied, and nothing is ever enqueued for that. Adopting is safe whatever the incoming value names: one naming an account a tombstone dominates has already been turned back into a repair before the comparison, so it stays unpublished and lands on the same target this device's repair did. Two more from the same trace: - Staged records are applied by category, and contexts already come last so that a repair reads the accounts and the instance a dominated record left behind rather than falling to local past a signed-in sibling. That ordering was load-bearing and unremarked; it is now written down, along with what it does not cover — a context applied in an earlier batch than the account record that says where the deleted account lived still repairs without it, which the next explicit choice anywhere settles. - An install that repaired its context before the repair bit existed reads back as having chosen it, so that one repair can still be published once. Accepted and documented at the load site: no shipped release ever persisted a data context, the window is interim builds only, and the next explicit choice heals it.