| Comment: | refactor(sync): separate the seeded-store check's error from its answer |
|---|---|
| Timelines: | family | ancestors | descendants | both | main | trunk | feat/horizon-peer-serving |
| Files: | files | file ages | folders |
| SHA3-256: |
2cac21987ff5780b2a8c4f1724872ccd |
| User & Date: | [email protected] on 2026-10-29 02:12:48.000 |
| Other Links: | branch diff | manifest | tags |
|
2026-10-29
| ||
| 03:02 |
fix(sync): judge the horizon refusal after the push, serve later peers
Review of #525. - A requested C this store cannot place is a peer ahead of it, not one asking for history it lacks, and is served what the store holds. A peer at a later C the store holds is placed inside its held set and served. - The refusal is judged after the card loop, once the pull card has passed its permission check and the push half is stored. Only the pull half is refused: the reply is reset to the one error card, the request is not rolled back, and a push in the same sync is kept. - The held sets are computed through the classification memo, which keeps them per store and drops them when the store changes; the inventory reuses the view the judgment read. - The refusal begins with the machine-readable prefix horizon-not-held:, which the client matches instead of the whole text. - The fallback remedy moves from a new result field into the existing diagnostics, prefixed horizon-fallback:: SyncResult.Errors and CloneResult.Messages. The CLI still prints it. check-in: ad975ea85b user: [email protected] tags: feat/horizon-peer-serving, main, trunk | |
| 02:12 | refactor(sync): separate the seeded-store check's error from its answer check-in: 2cac21987f user: [email protected] tags: feat/horizon-peer-serving, main, trunk | |
| 02:06 |
fix(sync): a horizon store refuses a pull it does not hold and mints no seed
A server over a horizon clone answered a horizon pull or sync at an earlier C from its own partial graph. It now refuses any horizon pull whose held set is not a subset of its own with one error card and no content, rolled back whole, and a go-libfossil client fails the round on that reply (draft-fossil-horizon-00 §6.4). partial-mirror serves it, as it does an uncovered clone. The clone coverage check now judges the horizon the request asked for, not the depth serving cut it to. A store at a structural horizon no longer mints a seed from its own seed: it answers a structural request at the content level (§6.2.3) and names its horizon-history-url. The requester falls back and reports HorizonRemedy, naming C and the dense origin that holds the manifests below it; the CLI prints it. The concept doc states when a horizon store may serve a horizon peer. Conformance covers §6.4 on the pull path, a structural store answering as content, and the fallback a structural clone takes from such a peer; zit pulls from a go-libfossil horizon store in both outcomes. Closes #490 check-in: 8802c5704f user: [email protected] tags: feat/horizon-peer-serving, main, trunk | |