Tags and Properties for Check-in f102c4c7ec
- branch=trunk inherited from [7619ba9563]
- sym-trunk inherited from [7619ba9563]
|
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 | |