flushBatchLocked in internal/routewatch/prefixhandler.go removes duplicates from each batch (about one second of updates) by prefix alone. For each prefix it keeps a single update across all peers: the one with the latest timestamp or, when several share a timestamp, the first. The feed's timestamps are cut to whole seconds when a message is read (ParsedTimestamp, set in stream in internal/streamer/streamer.go), so updates within one second all tie.
Failure scenarios, each confirmed with a throwaway test through PrefixHandler into a real database:
Three peers announce 198.51.100.0/24 in one batch: one route is stored and the other two peers' routes are lost. A routing change reaches most peers within the same second, so in normal operation most peers' updates are thrown away, and their routes stay missing or keep an old path.
A peer announces a prefix and withdraws it within the same second: the announcement is kept and the withdrawal dropped, so the route stays for good.
A peer withdraws a prefix and announces it again within the same second: the route is deleted and the new one is not stored.
Severity: critical
Definition of done
A test, failing before the fix, runs these three cases through PrefixHandler into a real database: one route per peer for the first, no route for the second, the route present for the third.
Within a batch, the update kept for each prefix and peer is the last one received, by arrival order, not by timestamp.
make check passes.
Model: opus-5-5
`flushBatchLocked` in `internal/routewatch/prefixhandler.go` removes duplicates from each batch (about one second of updates) by prefix alone. For each prefix it keeps a single update across all peers: the one with the latest timestamp or, when several share a timestamp, the first. The feed's timestamps are cut to whole seconds when a message is read (`ParsedTimestamp`, set in `stream` in `internal/streamer/streamer.go`), so updates within one second all tie.
Failure scenarios, each confirmed with a throwaway test through `PrefixHandler` into a real database:
- Three peers announce `198.51.100.0/24` in one batch: one route is stored and the other two peers' routes are lost. A routing change reaches most peers within the same second, so in normal operation most peers' updates are thrown away, and their routes stay missing or keep an old path.
- A peer announces a prefix and withdraws it within the same second: the announcement is kept and the withdrawal dropped, so the route stays for good.
- A peer withdraws a prefix and announces it again within the same second: the route is deleted and the new one is not stored.
Severity: critical
## Definition of done
- A test, failing before the fix, runs these three cases through `PrefixHandler` into a real database: one route per peer for the first, no route for the second, the route present for the third.
- Within a batch, the update kept for each prefix and peer is the last one received, by arrival order, not by timestamp.
- `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 14:50:30 +02:00
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.
flushBatchLockedininternal/routewatch/prefixhandler.goremoves duplicates from each batch (about one second of updates) by prefix alone. For each prefix it keeps a single update across all peers: the one with the latest timestamp or, when several share a timestamp, the first. The feed's timestamps are cut to whole seconds when a message is read (ParsedTimestamp, set instreamininternal/streamer/streamer.go), so updates within one second all tie.Failure scenarios, each confirmed with a throwaway test through
PrefixHandlerinto a real database:198.51.100.0/24in one batch: one route is stored and the other two peers' routes are lost. A routing change reaches most peers within the same second, so in normal operation most peers' updates are thrown away, and their routes stay missing or keep an old path.Severity: critical
Definition of done
PrefixHandlerinto a real database: one route per peer for the first, no route for the second, the route present for the third.make checkpasses.Model: opus-5-5
Duplicate of #54, filed in error by a parallel review; closing.
Model: opus-5-5