Head selection inside a slot picks the newest save by updated_at, and a tie keeps the first
element of the list. A save whose updated_at is missing or unparseable sorts as epoch 0, so two
such saves in the same slot tie at 0.0 — the tie does not need two writes in the same instant, which
is why I don't think it is unreachable.
The tie-break itself is specified and deterministic: strictly-greater comparison, first maximum
wins. What is not pinned down is the input order. The plugin passes the slot's saves to the
decision in whatever order RomM returned them — nothing sorts them first. If that order is not
stable across calls, the same on-disk and on-server state can select a different head between two
runs, and therefore reach a different sync decision.
No test covers this today: no fixture contains two saves with equal sort keys, so the behaviour is
unverified in both directions.
Two steps, deliberately separate:
- Pin the current behaviour. A test with two saves in one slot that both lack a parseable
updated_at: assert which one is selected, and that repeated runs select the same one.
- Then decide whether to order the slot explicitly — e.g. by ascending
id — so the tie
resolves on a stable key instead of on response order.
Step 2 changes an input to the sync decision, so it wants its own discussion and its own change; it
should not ride along in unrelated work. Step 1 is worth doing either way, because it is what makes
step 2's effect visible.
Not urgent — it needs a slot holding two saves that both lack a usable timestamp (migrated or older
records).
Head selection inside a slot picks the newest save by
updated_at, and a tie keeps the firstelement of the list. A save whose
updated_atis missing or unparseable sorts as epoch 0, so twosuch saves in the same slot tie at 0.0 — the tie does not need two writes in the same instant, which
is why I don't think it is unreachable.
The tie-break itself is specified and deterministic: strictly-greater comparison, first maximum
wins. What is not pinned down is the input order. The plugin passes the slot's saves to the
decision in whatever order RomM returned them — nothing sorts them first. If that order is not
stable across calls, the same on-disk and on-server state can select a different head between two
runs, and therefore reach a different sync decision.
No test covers this today: no fixture contains two saves with equal sort keys, so the behaviour is
unverified in both directions.
Two steps, deliberately separate:
updated_at: assert which one is selected, and that repeated runs select the same one.id— so the tieresolves on a stable key instead of on response order.
Step 2 changes an input to the sync decision, so it wants its own discussion and its own change; it
should not ride along in unrelated work. Step 1 is worth doing either way, because it is what makes
step 2's effect visible.
Not urgent — it needs a slot holding two saves that both lack a usable timestamp (migrated or older
records).