Every handler took the latest time per key in a batch and inserted it as a new row's first_seen. A key updated twice in one batch, seconds apart, was stored first seen at the later time, and the IP lookup could answer with a prefix first_seen after the route's last_seen.
PrefixHandler.flushBatch keeps, for each prefix, the earliest time among all of the batch's updates, announcements and withdrawals.
ASHandler.flushBatch, PeerHandler.flushBatch and the peering handler keep the earliest and the latest time per AS, peer and peering in the new database.SeenTimes. GetOrCreateASNBatch, UpdatePeerBatch and RecordPeering take it and store a new row first seen at the earliest and last seen at the latest.
What the diff does not show:
A stored row keeps its first_seen, even when a later batch has an earlier time; its last_seen is set to the batch's latest time, as before.
The peering handler kept one time per AS path, the last update's, so HandleMessage changes too.
SeenTimes.Add takes the zero time to mean no time yet; feed times come from time.Unix and are never zero.
Nothing reads the peer table back, so the peer handler's test checks what the handler writes, and a database test checks that UpdatePeerBatch stores it.
Disclosures:
Judgement call: every update counts, not only each peer's last, so one peer announcing a prefix twice in a batch also stores the first time.
TODO.md is not updated, as with the other audit fixes.
Model: opus-5-5
Implements https://git.eeqj.de/sneak/routewatch/issues/112.
What changed:
- Every handler took the latest time per key in a batch and inserted it as a new row's `first_seen`. A key updated twice in one batch, seconds apart, was stored first seen at the later time, and the IP lookup could answer with a prefix `first_seen` after the route's `last_seen`.
- `PrefixHandler.flushBatch` keeps, for each prefix, the earliest time among all of the batch's updates, announcements and withdrawals.
- `ASHandler.flushBatch`, `PeerHandler.flushBatch` and the peering handler keep the earliest and the latest time per AS, peer and peering in the new `database.SeenTimes`. `GetOrCreateASNBatch`, `UpdatePeerBatch` and `RecordPeering` take it and store a new row first seen at the earliest and last seen at the latest.
What the diff does not show:
- A stored row keeps its `first_seen`, even when a later batch has an earlier time; its `last_seen` is set to the batch's latest time, as before.
- The peering handler kept one time per AS path, the last update's, so `HandleMessage` changes too.
- `SeenTimes.Add` takes the zero time to mean no time yet; feed times come from `time.Unix` and are never zero.
- Nothing reads the peer table back, so the peer handler's test checks what the handler writes, and a database test checks that `UpdatePeerBatch` stores it.
Disclosures:
- Judgement call: every update counts, not only each peer's last, so one peer announcing a prefix twice in a batch also stores the first time.
- `TODO.md` is not updated, as with the other audit fixes.
Model: opus-5-5
Each handler took the latest time per key in a batch and inserted it as
a new row's first_seen, so a key updated twice in one batch, seconds
apart, was stored first seen at the later time, and the IP lookup could
answer with a prefix first_seen after the route's last_seen.
The prefix handler now keeps the earliest time of all of the batch's
updates for each prefix. The AS, peer and peering handlers keep the
earliest and the latest time per key in database.SeenTimes, and
GetOrCreateASNBatch, UpdatePeerBatch and RecordPeering store a new row
first seen at the earliest and last seen at the latest. A stored row
still has only its last_seen set, to the latest.
Model: opus-5-5
The PR now covers all four handlers, as the definition of done in #112 asks. The AS, peer and peering handlers keep the earliest and the latest time per key in the new database.SeenTimes, and GetOrCreateASNBatch, UpdatePeerBatch and RecordPeering store a new row first seen at the earliest and last seen at the latest. Each of those handlers has a new test with two updates 5 seconds apart in one batch, and UpdatePeerBatch has a database test, since nothing reads the peer table back. The PR body and the commit message now cover all four handlers.
Model: opus-5-5
The PR now covers all four handlers, as the definition of done in https://git.eeqj.de/sneak/routewatch/issues/112 asks. The AS, peer and peering handlers keep the earliest and the latest time per key in the new `database.SeenTimes`, and `GetOrCreateASNBatch`, `UpdatePeerBatch` and `RecordPeering` store a new row first seen at the earliest and last seen at the latest. Each of those handlers has a new test with two updates 5 seconds apart in one batch, and `UpdatePeerBatch` has a database test, since nothing reads the peer table back. The PR body and the commit message now cover all four handlers.
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.
Implements #112.
What changed:
first_seen. A key updated twice in one batch, seconds apart, was stored first seen at the later time, and the IP lookup could answer with a prefixfirst_seenafter the route'slast_seen.PrefixHandler.flushBatchkeeps, for each prefix, the earliest time among all of the batch's updates, announcements and withdrawals.ASHandler.flushBatch,PeerHandler.flushBatchand the peering handler keep the earliest and the latest time per AS, peer and peering in the newdatabase.SeenTimes.GetOrCreateASNBatch,UpdatePeerBatchandRecordPeeringtake it and store a new row first seen at the earliest and last seen at the latest.What the diff does not show:
first_seen, even when a later batch has an earlier time; itslast_seenis set to the batch's latest time, as before.HandleMessagechanges too.SeenTimes.Addtakes the zero time to mean no time yet; feed times come fromtime.Unixand are never zero.UpdatePeerBatchstores it.Disclosures:
TODO.mdis not updated, as with the other audit fixes.Model: opus-5-5
d64a734e7etod79e0dcd18The PR now covers all four handlers, as the definition of done in #112 asks. The AS, peer and peering handlers keep the earliest and the latest time per key in the new
database.SeenTimes, andGetOrCreateASNBatch,UpdatePeerBatchandRecordPeeringstore a new row first seen at the earliest and last seen at the latest. Each of those handlers has a new test with two updates 5 seconds apart in one batch, andUpdatePeerBatchhas a database test, since nothing reads the peer table back. The PR body and the commit message now cover all four handlers.Model: opus-5-5
Review passed.
Model: opus-5-5