When a RIS collector loses its BGP session with a peer, every route learned from that peer is gone, and RIS sends no withdrawals for them. routewatch keeps them.
Where: internal/streamer/streamer.go, stream: messages of type STATE (and RIS_PEER_STATE) are skipped, and NOTIFICATION only changes the peer count. ristypes.RISMessage does not decode the state field. The feed sends, for example (docs/message-examples.json):
Failure scenario: a peer at an exchange point goes down for an hour. Its few hundred thousand routes stay in the live tables; IP lookups and prefix pages keep listing routes through a peer that has none, and when the session comes back the peer only re-sends what it announces then, so routes it no longer has are never cleaned up.
Severity: high
Definition of done
A STATE message with state down from a peer removes all of that peer's live routes, IPv4 and IPv6, with the in-memory counts and prefix distribution kept exact. The removal goes through the prefix handler's batch, in feed order with that peer's updates, so an update the peer sends after the session comes back is not lost.
Routes are kept per peer IP, as now; if the same peer IP has sessions on two collectors, a down on one removes routes the other still carries until they are re-announced. Say so in one line in the README.
Tests that fail before the fix: a peer's routes are gone after its down; another peer's routes for the same prefixes stay.
make check passes.
Model: opus-5-5
When a RIS collector loses its BGP session with a peer, every route learned from that peer is gone, and RIS sends no withdrawals for them. routewatch keeps them.
Where: `internal/streamer/streamer.go`, `stream`: messages of type `STATE` (and `RIS_PEER_STATE`) are skipped, and `NOTIFICATION` only changes the peer count. `ristypes.RISMessage` does not decode the `state` field. The feed sends, for example (`docs/message-examples.json`):
`{"type":"ris_message","data":{"peer":"196.60.9.141","peer_asn":"328214","host":"rrc19.ripe.net","type":"STATE","state":"down",...}}`
Failure scenario: a peer at an exchange point goes down for an hour. Its few hundred thousand routes stay in the live tables; IP lookups and prefix pages keep listing routes through a peer that has none, and when the session comes back the peer only re-sends what it announces then, so routes it no longer has are never cleaned up.
Severity: high
## Definition of done
- A `STATE` message with state `down` from a peer removes all of that peer's live routes, IPv4 and IPv6, with the in-memory counts and prefix distribution kept exact. The removal goes through the prefix handler's batch, in feed order with that peer's updates, so an update the peer sends after the session comes back is not lost.
- Routes are kept per peer IP, as now; if the same peer IP has sessions on two collectors, a down on one removes routes the other still carries until they are re-announced. Say so in one line in the README.
- Tests that fail before the fix: a peer's routes are gone after its `down`; another peer's routes for the same prefixes stay.
- `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 14:33:44 +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.
When a RIS collector loses its BGP session with a peer, every route learned from that peer is gone, and RIS sends no withdrawals for them. routewatch keeps them.
Where:
internal/streamer/streamer.go,stream: messages of typeSTATE(andRIS_PEER_STATE) are skipped, andNOTIFICATIONonly changes the peer count.ristypes.RISMessagedoes not decode thestatefield. The feed sends, for example (docs/message-examples.json):{"type":"ris_message","data":{"peer":"196.60.9.141","peer_asn":"328214","host":"rrc19.ripe.net","type":"STATE","state":"down",...}}Failure scenario: a peer at an exchange point goes down for an hour. Its few hundred thousand routes stay in the live tables; IP lookups and prefix pages keep listing routes through a peer that has none, and when the session comes back the peer only re-sends what it announces then, so routes it no longer has are never cleaned up.
Severity: high
Definition of done
STATEmessage with statedownfrom a peer removes all of that peer's live routes, IPv4 and IPv6, with the in-memory counts and prefix distribution kept exact. The removal goes through the prefix handler's batch, in feed order with that peer's updates, so an update the peer sends after the session comes back is not lost.down; another peer's routes for the same prefixes stay.make checkpasses.Model: opus-5-5