stream in internal/streamer/streamer.go drops STATE messages without passing them to any handler ("Peer state changes - silently ignore"). When a collector's BGP session with a peer goes down, the feed sends one STATE message with "state":"down" and no withdrawals; in BGP every route learned over that session is gone at that moment. RouteWatch keeps all of them. When the session comes back the peer announces its current routes again, which refreshes them, but any prefix it no longer has stays for good.
Failure scenario: docs/message-examples.json, a few seconds of the live feed, holds two "state":"down" messages (196.60.9.141 and 196.60.8.57, both at rrc19). A full-table peer going down leaves up to about a million routes that the prefix pages and the IP lookup keep reporting as live, and that are never removed.
Severity: critical
Definition of done
A test, failing before the fix: routes of two peers stored through PrefixHandler into a real database, then a STATE message with "state":"down" for one of them. Afterwards that peer has no live routes, the other peer's routes remain, and the route counts and prefix distribution match the tables.
A "state":"down" message deletes every live route of that peer, in order with the peer's other updates: a route the peer announces after the down message in the same batch is kept.
make check passes.
Model: opus-5-5
`stream` in `internal/streamer/streamer.go` drops `STATE` messages without passing them to any handler ("Peer state changes - silently ignore"). When a collector's BGP session with a peer goes down, the feed sends one `STATE` message with `"state":"down"` and no withdrawals; in BGP every route learned over that session is gone at that moment. RouteWatch keeps all of them. When the session comes back the peer announces its current routes again, which refreshes them, but any prefix it no longer has stays for good.
Failure scenario: `docs/message-examples.json`, a few seconds of the live feed, holds two `"state":"down"` messages (`196.60.9.141` and `196.60.8.57`, both at `rrc19`). A full-table peer going down leaves up to about a million routes that the prefix pages and the IP lookup keep reporting as live, and that are never removed.
Severity: critical
## Definition of done
- A test, failing before the fix: routes of two peers stored through `PrefixHandler` into a real database, then a `STATE` message with `"state":"down"` for one of them. Afterwards that peer has no live routes, the other peer's routes remain, and the route counts and prefix distribution match the tables.
- A `"state":"down"` message deletes every live route of that peer, in order with the peer's other updates: a route the peer announces after the down message in the same batch is kept.
- `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 14:50:31 +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.
streamininternal/streamer/streamer.godropsSTATEmessages without passing them to any handler ("Peer state changes - silently ignore"). When a collector's BGP session with a peer goes down, the feed sends oneSTATEmessage with"state":"down"and no withdrawals; in BGP every route learned over that session is gone at that moment. RouteWatch keeps all of them. When the session comes back the peer announces its current routes again, which refreshes them, but any prefix it no longer has stays for good.Failure scenario:
docs/message-examples.json, a few seconds of the live feed, holds two"state":"down"messages (196.60.9.141and196.60.8.57, both atrrc19). A full-table peer going down leaves up to about a million routes that the prefix pages and the IP lookup keep reporting as live, and that are never removed.Severity: critical
Definition of done
PrefixHandlerinto a real database, then aSTATEmessage with"state":"down"for one of them. Afterwards that peer has no live routes, the other peer's routes remain, and the route counts and prefix distribution match the tables."state":"down"message deletes every live route of that peer, in order with the peer's other updates: a route the peer announces after the down message in the same batch is kept.make checkpasses.Model: opus-5-5
Duplicate of #56, filed in error by a parallel review; closing.
Model: opus-5-5