Skip to content
quarry Tags and Properties
Login

Tags and Properties

Tags and Properties for Check-in f102c4c7ec

Context
2026-08-25
13:04
Settling a landing is idempotent

Accepting an already-accepted landing wrote another state reply, and four stacked up on one record before it was noticed.

Two causes. The guard read state from the INDEX, which lags the store by an ingest round, so a second press inside that window saw 'open' and passed. And zit does not refuse the write either — an already-contained branch still gets a reply saying 'accepted', with 'nothing to merge' in the body.

So: fold first, re-read, then decide. A settle is deliberate and rare and can afford one ingest round to know what it is settling. And already-settled now succeeds writing nothing, because that is the end state the caller asked for; an error made a double press look broken when the landing was exactly as they wanted.

Proven against a running server: three accepts in a row leave one 'accepted this' reply and no 'nothing to merge'. check-in: f102c4c7ec user: dmestas tags: trunk

2026-08-14
20:06
root: RFCs, Go skeleton, ops registry core with import-graph gate check-in: 7619ba9563 user: dmestas tags: trunk