Looking up an address on /ip/ and /api/v1/ip/ read every IPv6 live route and, for IPv4, about half of the (ip_start, ip_end) index. GetIPInfoContext is now one function for both families: for each mask length from 32 or 128 down to 0 it looks up the address's network prefix with WHERE prefix = ? on the existing prefix index, and the first length with a live route wins. Peer count and first-seen come from the same query, as they already did for IPv4.
What the diff does not show:
The feed sends IPv6 announcements compressed (2001:db8::/48) but IPv6 withdrawals uncompressed (2001:db8:0:0:0:0:0:0/48). Prefixes were stored as received, so an IPv6 withdrawal never removed its route. The prefix handler now stores every prefix in the text form net/netip prints, the form the lookup builds, so IPv6 withdrawals take effect and a running instance will hold fewer IPv6 live routes than before.
ip_start/ip_end, their index and the code that fills them are removed: nothing reads them after this change.
GetASInfoForIP and GetASInfoForIPContext are removed from the store, its interface and the test mock; nothing else called them.
Disclosures:
A database created before this change must be deleted: its live_routes_v4 still requires the removed columns, so IPv4 writes would fail.
Judgement call: the IPv4 and IPv6 upsert helpers are now the same apart from their statements; merging them is left out to stay clear of the concurrent change for #30.
The large-database check the issue asks for was run within the memory budget; the database was deleted afterwards.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/routewatch/issues/48.
Looking up an address on `/ip/` and `/api/v1/ip/` read every IPv6 live route and, for IPv4, about half of the `(ip_start, ip_end)` index. `GetIPInfoContext` is now one function for both families: for each mask length from 32 or 128 down to 0 it looks up the address's network prefix with `WHERE prefix = ?` on the existing prefix index, and the first length with a live route wins. Peer count and first-seen come from the same query, as they already did for IPv4.
What the diff does not show:
- The feed sends IPv6 announcements compressed (`2001:db8::/48`) but IPv6 withdrawals uncompressed (`2001:db8:0:0:0:0:0:0/48`). Prefixes were stored as received, so an IPv6 withdrawal never removed its route. The prefix handler now stores every prefix in the text form `net/netip` prints, the form the lookup builds, so IPv6 withdrawals take effect and a running instance will hold fewer IPv6 live routes than before.
- `ip_start`/`ip_end`, their index and the code that fills them are removed: nothing reads them after this change.
- `GetASInfoForIP` and `GetASInfoForIPContext` are removed from the store, its interface and the test mock; nothing else called them.
Disclosures:
- A database created before this change must be deleted: its `live_routes_v4` still requires the removed columns, so IPv4 writes would fail.
- Judgement call: the IPv4 and IPv6 upsert helpers are now the same apart from their statements; merging them is left out to stay clear of the concurrent change for https://git.eeqj.de/sneak/routewatch/issues/30.
- The large-database check the issue asks for was run within the memory budget; the database was deleted afterwards.
Model: opus-5-5
Looking up an address read every IPv6 live route and, for IPv4, about
half of the range index. Both families now look the address's prefix up
at each mask length, longest first, on the prefix index: at most 33 or
129 indexed lookups, however many routes are live.
The feed sends IPv6 withdrawals uncompressed but announcements
compressed, so the prefix handler now stores every prefix in the text
form net/netip prints, the form the lookup builds. IPv6 withdrawals now
remove their routes.
The IPv4 range columns, their index and the code that fills them are
removed, and so are the unused GetASInfoForIP lookups.
Model: opus-5-5
clawbot
self-assigned this 2026-10-03 14:58:16 +02:00
Review passed. #50 rewrites the same IPv4 and IPv6 upsert helpers, which this change leaves identical, so whichever lands second needs a rebase and can merge them.
Model: opus-5-5
Review passed.
https://git.eeqj.de/sneak/routewatch/pulls/50 rewrites the same IPv4 and IPv6 upsert helpers, which this change leaves identical, so whichever lands second needs a rebase and can merge them.
Model: opus-5-5
clawbot
merged commit 32704c601e into next2026-10-03 16:04:39 +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.
Fixes #48.
Looking up an address on
/ip/and/api/v1/ip/read every IPv6 live route and, for IPv4, about half of the(ip_start, ip_end)index.GetIPInfoContextis now one function for both families: for each mask length from 32 or 128 down to 0 it looks up the address's network prefix withWHERE prefix = ?on the existing prefix index, and the first length with a live route wins. Peer count and first-seen come from the same query, as they already did for IPv4.What the diff does not show:
2001:db8::/48) but IPv6 withdrawals uncompressed (2001:db8:0:0:0:0:0:0/48). Prefixes were stored as received, so an IPv6 withdrawal never removed its route. The prefix handler now stores every prefix in the text formnet/netipprints, the form the lookup builds, so IPv6 withdrawals take effect and a running instance will hold fewer IPv6 live routes than before.ip_start/ip_end, their index and the code that fills them are removed: nothing reads them after this change.GetASInfoForIPandGetASInfoForIPContextare removed from the store, its interface and the test mock; nothing else called them.Disclosures:
live_routes_v4still requires the removed columns, so IPv4 writes would fail.Model: opus-5-5
Review passed.
#50 rewrites the same IPv4 and IPv6 upsert helpers, which this change leaves identical, so whichever lands second needs a rebase and can merge them.
Model: opus-5-5