Client does not regenerate its Loro peer id on a PEER_ID_COLLISION refusal

[farhan-syah]

Summary

Origin now refuses a delta whose Loro peer id is owned by another replica, with a terminal DeltaReject carrying PEER_ID_COLLISION and a Custom { constraint: "peer_id_collision" } compensation hint (NodeDB-Lab/nodedb#214). The refusal is loud and diagnosable, but no client acts on it.

A replica that hits this is permanently broken from that point: every write it pushes under the colliding peer id is refused, and nothing recovers unless a human reads the log and reinstalls the client.

Expected

On receiving a peer_id_collision refusal, the client should regenerate its Loro peer id for the affected collection and resync, rather than abandoning the write and continuing to push under an id the server will keep refusing.

Why this matters

The refusal replaced a silent-data-loss path — the merge used to discard those writes with a successful ack. Turning silent loss into loud, permanent failure is a strict improvement, but the recovery it implies is currently manual. Automatic recovery is the difference between "an operator eventually notices" and "the replica heals itself".

Notes

Two related cases the server deliberately cannot refuse, both of which the client is the only layer able to prevent:

• A client that wipes its local CRDT store but keeps its lite_id and peer id collides with its own earlier history. The server owns no basis to reject it (the producer really does own that peer id), so those writes are reported Duplicate and dropped. The client should generate a new peer id whenever its local store is reset, reinstalled, or restored from another replica's backup.
• A session that connects without a lite_id has no durable producer identity for a peer id to be bound to at all.

[farhan-syah]

Fixed in 6b575ae.

The peer id is no longer supplied by the caller. It is minted per store on first open and persisted alongside lite_id and epoch, so two installs of the same application no longer share a producer identity, and a rotation survives a restart instead of being forgotten.

On a peer_id_collision refusal the client now rotates: it mints a new peer id, re-authors every collection under it, and re-queues every row for resync. Rebuilding the documents is necessary rather than just changing the id future writes carry — Loro fixes an operation's peer id at commit time, so the existing operations would keep being refused.

Also addressed from the notes:

• A store that is reset, reinstalled, or restored from another replica mints its own peer id, because the identity belongs to the store rather than to the caller's argument.
• fork_detected in the handshake ack was being ignored. It now regenerates the whole producer identity (lite_id, epoch, and peer id) and resyncs.
• The handshake could previously send an empty lite_id. The identity is now always present, so a session always has a durable producer identity for a peer id to be bound to.

Two related defects found while fixing this:

• A collision refusal was being resolved as if the row had violated a constraint, which deleted the local row and dropped the write. The row was never the problem, so it is now preserved and re-pushed.
• The vector, FTS, spatial, columnar, and timeseries push paths were sending a stringified peer id in the wire's lite_id field, so Origin deduplicated those entries under an identifier that did not match the handshake.

Rotation preserves nested containers and bitemporal history, and refuses rather than proceeding if anything cannot be reproduced. Covered by tests/peer_identity.rs, tests/compensation.rs, and a dispatch test asserting a collision refusal reaches the rotation path and not the rollback path.

Requires the companion CrdtState::rekey primitive in the shared CRDT crate.