Artifact 9936e84fbbeb28657774ac47186710ebb8c2458c54932f47255ecd88ba23b417:
- File
conformance/horizon_peer_zit_test.go
-
2026-10-29 03:45:23
— part of check-in
[a557971c28]
on branch feat/horizon-peer-serving
— 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". (user: [email protected], size: 4049) [annotate] [blame] [check-ins using]
-
2026-10-29 05:35:02
— part of check-in
[301c8e2337]
on branch main
— 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 (user: [email protected], size: 4049) [annotate] [blame] [check-ins using]
-
2026-10-29 03:45:23
— part of check-in
[a557971c28]
on branch feat/horizon-peer-serving
— fix(sync): a refused horizon sync still takes the peer's push