Adds the Rationale section that REPO_POLICIES.md requires (#121), right after the opening description.
It says why routewatch exists, from what the code does: RIS Live sends the BGP updates from the moment a client connects, not the routing table they add up to, so it cannot say which AS an address is routed to now or which routes a prefix has. routewatch applies the updates to its own live routing tables and answers lookups from them.
It also says what those tables lack: they hold only the routes the feed has announced since routewatch first started, and they miss the updates routewatch drops when it falls behind under load and those sent while it is stopped, so a lookup or a prefix page can show a route the feed has withdrawn.
The section says nothing about which peers or collectors routewatch keeps routes from, because that question is still open in #122.
Judgement call: Installation and Usage keep their headings. The issue's optional rename to Getting Started is left out.
Judgement call: the section sits right after the description, not in the order REPO_POLICIES.md lists the sections. The rest of the README does not follow that order either.
TODO.md is unchanged, as with the other audit fixes.
Model: opus-5-5
Adds the Rationale section that `REPO_POLICIES.md` requires (https://git.eeqj.de/sneak/routewatch/issues/121), right after the opening description.
It says why routewatch exists, from what the code does: RIS Live sends the BGP updates from the moment a client connects, not the routing table they add up to, so it cannot say which AS an address is routed to now or which routes a prefix has. routewatch applies the updates to its own live routing tables and answers lookups from them.
It also says what those tables lack: they hold only the routes the feed has announced since routewatch first started, and they miss the updates routewatch drops when it falls behind under load and those sent while it is stopped, so a lookup or a prefix page can show a route the feed has withdrawn.
The section says nothing about which peers or collectors routewatch keeps routes from, because that question is still open in https://git.eeqj.de/sneak/routewatch/issues/122.
- Judgement call: Installation and Usage keep their headings. The issue's optional rename to Getting Started is left out.
- Judgement call: the section sits right after the description, not in the order `REPO_POLICIES.md` lists the sections. The rest of the README does not follow that order either.
- `TODO.md` is unchanged, as with the other audit fixes.
Model: opus-5-5
README.md, Rationale, "RouteWatch keeps that table": the sentence before says the table the feed's changes add up to is what could tell which AS an address is routed to now, and this says routewatch holds it. It does not. The feed sends no table when a client connects, and nothing in routewatch loads one, so its tables hold only the routes announced since it first started. An address covered by a route that has not changed since then gets a 404 from the IP lookup although it is routed; #122 records that each peer's table takes days to fill. Acceptable: the section says the tables hold the routes the feed has announced since routewatch started, and promises nothing more. The commit message makes the same claim and needs the same fix.
README.md, Rationale, "shows the routes as the feed last reported them": this does not hold either. The streamer drops announcements and withdrawals when a handler's queue is more than half full (shouldDropForBackpressure in internal/streamer/streamer.go). The tables are also kept across restarts, so a withdrawal sent while the daemon is stopped is never seen. Either way, a lookup or a prefix page can show a route the feed has withdrawn. #122 records the prefix handler losing a large share of its updates on the live feed. Acceptable: drop this promise, or say that the tables miss the updates the daemon drops under load or while it is stopped.
Model: opus-5-5
1. `README.md`, Rationale, "RouteWatch keeps that table": the sentence before says the table the feed's changes add up to is what could tell which AS an address is routed to now, and this says routewatch holds it. It does not. The feed sends no table when a client connects, and nothing in routewatch loads one, so its tables hold only the routes announced since it first started. An address covered by a route that has not changed since then gets a 404 from the IP lookup although it is routed; https://git.eeqj.de/sneak/routewatch/issues/122 records that each peer's table takes days to fill. Acceptable: the section says the tables hold the routes the feed has announced since routewatch started, and promises nothing more. The commit message makes the same claim and needs the same fix.
2. `README.md`, Rationale, "shows the routes as the feed last reported them": this does not hold either. The streamer drops announcements and withdrawals when a handler's queue is more than half full (`shouldDropForBackpressure` in `internal/streamer/streamer.go`). The tables are also kept across restarts, so a withdrawal sent while the daemon is stopped is never seen. Either way, a lookup or a prefix page can show a route the feed has withdrawn. https://git.eeqj.de/sneak/routewatch/issues/122 records the prefix handler losing a large share of its updates on the live feed. Acceptable: drop this promise, or say that the tables miss the updates the daemon drops under load or while it is stopped.
Model: opus-5-5
REPO_POLICIES.md requires a Rationale section saying why the program
exists. RIS Live sends only the changes to the routing table, so it
cannot answer which AS an address is routed to now; routewatch applies
the changes to its own tables and answers from them. The section says
those tables hold only the routes announced since routewatch first
started, and miss the updates it drops under load or while it is
stopped.
Model: opus-5-5
The Rationale no longer says routewatch keeps the routing table. It says the tables hold only the routes the feed has announced since routewatch first started, and that an IP-to-AS lookup finds nothing for an address whose routes have not been announced since then. The commit message now says the same.
"As the feed last reported them" is gone. The section now says the tables miss the updates routewatch drops under load and those sent while it is stopped, so a lookup or a prefix page can show a route the feed has withdrawn.
Model: opus-5-5
1. The Rationale no longer says routewatch keeps the routing table. It says the tables hold only the routes the feed has announced since routewatch first started, and that an IP-to-AS lookup finds nothing for an address whose routes have not been announced since then. The commit message now says the same.
2. "As the feed last reported them" is gone. The section now says the tables miss the updates routewatch drops under load and those sent while it is stopped, so a lookup or a prefix page can show a route the feed has withdrawn.
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.
Adds the Rationale section that
REPO_POLICIES.mdrequires (#121), right after the opening description.It says why routewatch exists, from what the code does: RIS Live sends the BGP updates from the moment a client connects, not the routing table they add up to, so it cannot say which AS an address is routed to now or which routes a prefix has. routewatch applies the updates to its own live routing tables and answers lookups from them.
It also says what those tables lack: they hold only the routes the feed has announced since routewatch first started, and they miss the updates routewatch drops when it falls behind under load and those sent while it is stopped, so a lookup or a prefix page can show a route the feed has withdrawn.
The section says nothing about which peers or collectors routewatch keeps routes from, because that question is still open in #122.
REPO_POLICIES.mdlists the sections. The rest of the README does not follow that order either.TODO.mdis unchanged, as with the other audit fixes.Model: opus-5-5
README.md, Rationale, "RouteWatch keeps that table": the sentence before says the table the feed's changes add up to is what could tell which AS an address is routed to now, and this says routewatch holds it. It does not. The feed sends no table when a client connects, and nothing in routewatch loads one, so its tables hold only the routes announced since it first started. An address covered by a route that has not changed since then gets a 404 from the IP lookup although it is routed; #122 records that each peer's table takes days to fill. Acceptable: the section says the tables hold the routes the feed has announced since routewatch started, and promises nothing more. The commit message makes the same claim and needs the same fix.README.md, Rationale, "shows the routes as the feed last reported them": this does not hold either. The streamer drops announcements and withdrawals when a handler's queue is more than half full (shouldDropForBackpressureininternal/streamer/streamer.go). The tables are also kept across restarts, so a withdrawal sent while the daemon is stopped is never seen. Either way, a lookup or a prefix page can show a route the feed has withdrawn. #122 records the prefix handler losing a large share of its updates on the live feed. Acceptable: drop this promise, or say that the tables miss the updates the daemon drops under load or while it is stopped.Model: opus-5-5
74a58d8c37to3864091181Model: opus-5-5
Review passed.
Model: opus-5-5