The prefix handler's batch kept one update per prefix across all peers, picked by timestamp. One routing change reaches many peers within the same second, so most peers' announcements and withdrawals in a batch were dropped; and because timestamps are whole seconds and an equal one did not replace the kept update, the first update in a second won.
The batch now keeps the last update per prefix and peer, in the order the feed delivered them. Updates for the same prefix from different peers are all applied. A message's withdrawals are now queued before its announcements, so a message that lists a prefix as both withdrawn and announced keeps the route, as RFC 4271 section 4.3 asks.
The new test runs one prefix through the handler into a real database: two peers announce in one batch, two peers withdraw in one batch, one peer announces then withdraws, or withdraws then re-announces, in the same second, and one message both announces and withdraws the prefix. Each case also checks that the in-memory route count and prefix distribution match the route table.
Worth knowing:
Announcements are still written before withdrawals in each flush. With at most one update per prefix and peer, the two no longer touch the same route.
The debug log's unique_prefixes now counts prefixes; the kept updates are per prefix and peer.
A peer changing a prefix's origin AS, and withdrawals sent alongside announcements, still leave a stale route; that is #55.
Judgement call: README.md is unchanged, as nothing in it is made wrong by this.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/routewatch/issues/54.
The prefix handler's batch kept one update per prefix across all peers, picked by timestamp. One routing change reaches many peers within the same second, so most peers' announcements and withdrawals in a batch were dropped; and because timestamps are whole seconds and an equal one did not replace the kept update, the first update in a second won.
The batch now keeps the last update per prefix and peer, in the order the feed delivered them. Updates for the same prefix from different peers are all applied. A message's withdrawals are now queued before its announcements, so a message that lists a prefix as both withdrawn and announced keeps the route, as RFC 4271 section 4.3 asks.
The new test runs one prefix through the handler into a real database: two peers announce in one batch, two peers withdraw in one batch, one peer announces then withdraws, or withdraws then re-announces, in the same second, and one message both announces and withdraws the prefix. Each case also checks that the in-memory route count and prefix distribution match the route table.
Worth knowing:
- Announcements are still written before withdrawals in each flush. With at most one update per prefix and peer, the two no longer touch the same route.
- The debug log's `unique_prefixes` now counts prefixes; the kept updates are per prefix and peer.
- A peer changing a prefix's origin AS, and withdrawals sent alongside announcements, still leave a stale route; that is https://git.eeqj.de/sneak/routewatch/issues/55.
- Judgement call: `README.md` is unchanged, as nothing in it is made wrong by this.
Model: opus-5-5
internal/routewatch/prefixhandler.go, HandleMessage: a message that lists the same prefix as both announced and withdrawn now removes that peer's route. HandleMessage queues a message's announcements before its withdrawals, so under the new rule (keep the last update per prefix and peer) the withdrawal wins. In a BGP update the withdrawals come first and the announcement is what counts (RFC 4271 section 4.3); the code before this change kept the route. The route then stays missing until the peer announces it again, the same loss the issue describes. Acceptable: HandleMessage queues a message's withdrawals before its announcements, and the new test gets a case where one message announces and withdraws the prefix and the peer's route remains, with the in-memory counts and prefix distribution checked as in the other cases.
Model: opus-5-5
- `internal/routewatch/prefixhandler.go`, `HandleMessage`: a message that lists the same prefix as both announced and withdrawn now removes that peer's route. `HandleMessage` queues a message's announcements before its withdrawals, so under the new rule (keep the last update per prefix and peer) the withdrawal wins. In a BGP update the withdrawals come first and the announcement is what counts (RFC 4271 section 4.3); the code before this change kept the route. The route then stays missing until the peer announces it again, the same loss the issue describes. Acceptable: `HandleMessage` queues a message's withdrawals before its announcements, and the new test gets a case where one message announces and withdraws the prefix and the peer's route remains, with the in-memory counts and prefix distribution checked as in the other cases.
Model: opus-5-5
The prefix handler's batch kept one update per prefix across all peers,
chosen by timestamp. One routing change reaches many peers within a second,
so most peers' announcements and withdrawals in a batch were dropped, and
for updates in the same second the first one won.
The batch now keeps the last update per prefix and peer, in the order the
feed delivered them, so updates from every peer are applied. A message's
withdrawals are queued before its announcements, so a message that lists a
prefix as both keeps the route (RFC 4271 section 4.3). Tests cover each case
and check the in-memory route count and prefix distribution against the
route table.
Model: opus-5-5
HandleMessage now queues a message's withdrawals before its announcements, so a message that lists a prefix as both keeps the peer's route; the test has a new case for it ("one message announces and withdraws the prefix") with the in-memory counts and prefix distribution checked.
Model: opus-5-5
- `HandleMessage` now queues a message's withdrawals before its announcements, so a message that lists a prefix as both keeps the peer's route; the test has a new case for it ("one message announces and withdraws the prefix") with the in-memory counts and prefix distribution checked.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #54.
The prefix handler's batch kept one update per prefix across all peers, picked by timestamp. One routing change reaches many peers within the same second, so most peers' announcements and withdrawals in a batch were dropped; and because timestamps are whole seconds and an equal one did not replace the kept update, the first update in a second won.
The batch now keeps the last update per prefix and peer, in the order the feed delivered them. Updates for the same prefix from different peers are all applied. A message's withdrawals are now queued before its announcements, so a message that lists a prefix as both withdrawn and announced keeps the route, as RFC 4271 section 4.3 asks.
The new test runs one prefix through the handler into a real database: two peers announce in one batch, two peers withdraw in one batch, one peer announces then withdraws, or withdraws then re-announces, in the same second, and one message both announces and withdraws the prefix. Each case also checks that the in-memory route count and prefix distribution match the route table.
Worth knowing:
unique_prefixesnow counts prefixes; the kept updates are per prefix and peer.README.mdis unchanged, as nothing in it is made wrong by this.Model: opus-5-5
internal/routewatch/prefixhandler.go,HandleMessage: a message that lists the same prefix as both announced and withdrawn now removes that peer's route.HandleMessagequeues a message's announcements before its withdrawals, so under the new rule (keep the last update per prefix and peer) the withdrawal wins. In a BGP update the withdrawals come first and the announcement is what counts (RFC 4271 section 4.3); the code before this change kept the route. The route then stays missing until the peer announces it again, the same loss the issue describes. Acceptable:HandleMessagequeues a message's withdrawals before its announcements, and the new test gets a case where one message announces and withdraws the prefix and the peer's route remains, with the in-memory counts and prefix distribution checked as in the other cases.Model: opus-5-5
070f2025ccto423fb0fc55HandleMessagenow queues a message's withdrawals before its announcements, so a message that lists a prefix as both keeps the peer's route; the test has a new case for it ("one message announces and withdraws the prefix") with the in-memory counts and prefix distribution checked.Model: opus-5-5
Review passed.
Model: opus-5-5