9 check-ins related to "feat/horizon-peer-serving"
|
2026-10-29
| ||
| 05:35 |
Merge pull request #525 from danmestas/feat/horizon-peer-serving
fix(sync): a horizon store refuses a pull it does not hold and mints no seed check-in: 301c8e2337 user: [email protected] tags: main, trunk | |
| 04:57 |
refactor(sync): keep an allowlist of reply cards on a horizon refusal
A refusal keeps only gimmes, errors, messages and the session-level pragmas, so a pull-side card type added later is dropped until judged safe. The refused-pull case now asks for every pull-side card kind and asserts the reply holds only allowlisted types. check-in: fb36eb5653 user: [email protected] tags: feat/horizon-peer-serving, main, trunk | |
| 04:21 | Merge remote-tracking branch 'origin/main' into feat/horizon-peer-serving leaf check-in: fa65d2c2d5 user: [email protected] tags: feat/horizon-peer-serving, main, trunk | |
| 03:45 |
fix(sync): a refused horizon sync still takes the peer's push
Re-review of #525. Resetting the reply after the card loop dropped the gimmes that answer the client's igot announcements. The real client sends only igots in its first round, so its push never landed. - Server: a §6.4 refusal drops only what the pull half put in the reply. That is content, announcements and the pragmas serving the horizon. The push half's cards stay, its gimmes and any push error, and the horizon-not-held error goes last, since a client stops reading at an error card. - Client: on a horizon-not-held refusal the pull stops and later requests carry no pull card. Rounds go on answering gimmes until the push converges, bounded by MaxRounds, and Sync then returns the refusal. A structural store does not read the refusal as a reason to fall back. - The refused-push case now drives the real client: an earlier-C peer with a check-in of its own syncs, and the store holds that check-in while the peer is sent no content. A push error survives the refusal. - The requirement table and concept doc say why taking the push is consistent with §6.4's "no content". check-in: a557971c28 user: [email protected] tags: feat/horizon-peer-serving, main, trunk | |
| 03:30 |
Merge pull request #526 from danmestas/perf/wasm-size-and-refusal
Return receive-budget refusals as *RefusedError; libfossil_nohttp tag cuts the TinyGo engine ~97 KB check-in: 0ffed7ff5f user: [email protected] tags: main, trunk | |
| 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 | |
| 01:51 |
Merge pull request #524 from danmestas/feat/receive-size-budget
feat(sync): per-store artifact size budget on the receive path check-in: d385bc8746 user: [email protected] tags: main, trunk | |