What is wrong. For an AS registered with APNIC, the stored last-modified date is the date of the AS block the AS sits in, not the AS's own. APNIC's answer for AS4608 starts with the block's object, last modified 2019-05-20, before the aut-num object, last modified 2026-08-26. The parser in internal/whois keeps the first value it sees for each field, so it stores 2019-05-20. Other fields that appear in both objects may be taken from the block in the same way.
What acceptable looks like. The fields come from the aut-num object (and the organisation object it names), not from an as-block object that comes before it in the answer.
Definition of done.
A test that fails on the current code, built from an APNIC answer that starts with an AS block: the AS's own last-modified date is stored.
The fix in internal/whois.
One reviewed PR into next.
Model: opus-5-5
**What is wrong.** For an AS registered with APNIC, the stored last-modified date is the date of the AS block the AS sits in, not the AS's own. APNIC's answer for `AS4608` starts with the block's object, last modified 2019-05-20, before the `aut-num` object, last modified 2026-08-26. The parser in `internal/whois` keeps the first value it sees for each field, so it stores 2019-05-20. Other fields that appear in both objects may be taken from the block in the same way.
**What acceptable looks like.** The fields come from the `aut-num` object (and the organisation object it names), not from an `as-block` object that comes before it in the answer.
**Definition of done.**
- A test that fails on the current code, built from an APNIC answer that starts with an AS block: the AS's own last-modified date is stored.
- The fix in `internal/whois`.
- One reviewed PR into `next`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-26 23:12:58 +01:00
Fixed in #175. For answers from RIPE, APNIC and AFRINIC, the parser now reads only the aut-num object and the organisation object it names. RIPE's answers also start with an as-block object, so RIPE ASes had the block's dates too, and the fix covers them.
Model: opus-5-5
Fixed in https://git.eeqj.de/sneak/routewatch/pulls/175. For answers from RIPE, APNIC and AFRINIC, the parser now reads only the `aut-num` object and the organisation object it names. RIPE's answers also start with an `as-block` object, so RIPE ASes had the block's dates too, and the fix covers them.
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. For an AS registered with APNIC, the stored last-modified date is the date of the AS block the AS sits in, not the AS's own. APNIC's answer for
AS4608starts with the block's object, last modified 2019-05-20, before theaut-numobject, last modified 2026-08-26. The parser ininternal/whoiskeeps the first value it sees for each field, so it stores 2019-05-20. Other fields that appear in both objects may be taken from the block in the same way.What acceptable looks like. The fields come from the
aut-numobject (and the organisation object it names), not from anas-blockobject that comes before it in the answer.Definition of done.
internal/whois.next.Model: opus-5-5
Fixed in #175. For answers from RIPE, APNIC and AFRINIC, the parser now reads only the
aut-numobject and the organisation object it names. RIPE's answers also start with anas-blockobject, so RIPE ASes had the block's dates too, and the fix covers them.Model: opus-5-5