What is wrong. On the AS page's peer list, "First Seen" can be later than "Last Seen". On a fresh database, AS3356's page listed AS101 as first seen 2026-10-25 and last seen 2026-10-05.
Why. Some RIS collectors send updates whose timestamps are days or weeks old; they are catching up on a backlog. In a run of a few minutes, nine peers sent about a fifth of all routes with timestamps 1 to 21 days old. Each write sets last_seen to the update's time, even when that time is older than the stored one. first_seen is set once, from whichever update came first. The same applies to the last_seen of asns, peerings and bgp_peers in internal/database/database.go.
What acceptable looks like.last_seen only moves forward and first_seen only moves back: a write keeps the later of the stored and new last-seen times, and the earlier of the stored and new first-seen times. This holds for ASes, peerings and BGP peers. The route times stay as they are: a route's time is the time its peer sent it.
Definition of done.
A test that fails on the current code: an older update after a newer one leaves last_seen at the newer time, and an older update lowers first_seen.
The fix in internal/database, for ASes, peerings and BGP peers.
One reviewed PR into next.
Model: opus-5-5
**What is wrong.** On the AS page's peer list, "First Seen" can be later than "Last Seen". On a fresh database, AS3356's page listed AS101 as first seen 2026-10-25 and last seen 2026-10-05.
**Why.** Some RIS collectors send updates whose timestamps are days or weeks old; they are catching up on a backlog. In a run of a few minutes, nine peers sent about a fifth of all routes with timestamps 1 to 21 days old. Each write sets `last_seen` to the update's time, even when that time is older than the stored one. `first_seen` is set once, from whichever update came first. The same applies to the `last_seen` of `asns`, `peerings` and `bgp_peers` in `internal/database/database.go`.
**What acceptable looks like.** `last_seen` only moves forward and `first_seen` only moves back: a write keeps the later of the stored and new last-seen times, and the earlier of the stored and new first-seen times. This holds for ASes, peerings and BGP peers. The route times stay as they are: a route's time is the time its peer sent it.
**Definition of done.**
- A test that fails on the current code: an older update after a newer one leaves `last_seen` at the newer time, and an older update lowers `first_seen`.
- The fix in `internal/database`, for ASes, peerings and BGP peers.
- One reviewed PR into `next`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-26 21:15:39 +01:00
#170 makes every update to a stored AS, peering or peer keep the earlier first-seen time and the later last-seen time. The rule is in the SQL, and the batch and single-row writes share it. An older update to a peer still sets the peer's AS and last message type; that is outside this issue.
Model: opus-5-5
https://git.eeqj.de/sneak/routewatch/pulls/170 makes every update to a stored AS, peering or peer keep the earlier first-seen time and the later last-seen time. The rule is in the SQL, and the batch and single-row writes share it. An older update to a peer still sets the peer's AS and last message type; that is outside this issue.
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.
What is wrong. On the AS page's peer list, "First Seen" can be later than "Last Seen". On a fresh database, AS3356's page listed AS101 as first seen 2026-10-25 and last seen 2026-10-05.
Why. Some RIS collectors send updates whose timestamps are days or weeks old; they are catching up on a backlog. In a run of a few minutes, nine peers sent about a fifth of all routes with timestamps 1 to 21 days old. Each write sets
last_seento the update's time, even when that time is older than the stored one.first_seenis set once, from whichever update came first. The same applies to thelast_seenofasns,peeringsandbgp_peersininternal/database/database.go.What acceptable looks like.
last_seenonly moves forward andfirst_seenonly moves back: a write keeps the later of the stored and new last-seen times, and the earlier of the stored and new first-seen times. This holds for ASes, peerings and BGP peers. The route times stay as they are: a route's time is the time its peer sent it.Definition of done.
last_seenat the newer time, and an older update lowersfirst_seen.internal/database, for ASes, peerings and BGP peers.next.Model: opus-5-5
#170 makes every update to a stored AS, peering or peer keep the earlier first-seen time and the later last-seen time. The rule is in the SQL, and the batch and single-row writes share it. An older update to a peer still sets the peer's AS and last message type; that is outside this issue.
Model: opus-5-5