After a failure the wait before the next lookup grows by half instead of doubling, and it never exceeds one minute (was five). A success still halves it, down to one second.
RIPE's WHOIS refuses a host for good after repeated excessive querying. A test run from our build host got "%ERROR:201: access denied ... permanently denied because of a repeated excessive querying" on every RIPE lookup, and every RIPE AS failed. RIPE counts the person and role objects a query returns against a daily limit per address, and a plain AS<n> query returns them. So the RIPE queries change to the form RIPE documents for leaving those objects out (the -r flag), and the AS name, organisation and abuse address come from objects that do not count against the limit. Without this, a faster fetcher gets your host refused by RIPE sooner.
An "access denied" or rate-limit answer from any RIR is logged as such, not as "no WHOIS fields".
A failed AS stays stale, and the next lookup picks a random stale AS, so one bad AS cannot hold up the rest.
Model: opus-5-5
Plan:
- After a failure the wait before the next lookup grows by half instead of doubling, and it never exceeds one minute (was five). A success still halves it, down to one second.
- RIPE's WHOIS refuses a host for good after repeated excessive querying. A test run from our build host got "%ERROR:201: access denied ... permanently denied because of a repeated excessive querying" on every RIPE lookup, and every RIPE AS failed. RIPE counts the person and role objects a query returns against a daily limit per address, and a plain `AS<n>` query returns them. So the RIPE queries change to the form RIPE documents for leaving those objects out (the `-r` flag), and the AS name, organisation and abuse address come from objects that do not count against the limit. Without this, a faster fetcher gets your host refused by RIPE sooner.
- An "access denied" or rate-limit answer from any RIR is logged as such, not as "no WHOIS fields".
A failed AS stays stale, and the next lookup picks a random stale AS, so one bad AS cannot hold up the rest.
Model: opus-5-5
RIPE, APNIC and AFRINIC are asked with --no-personal, not -r. It leaves out only person and role objects, so the organisation's name and country still come in the same answer.
ARIN and LACNIC are unchanged.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/routewatch/pulls/167.
One change from the plan:
- RIPE, APNIC and AFRINIC are asked with `--no-personal`, not `-r`. It leaves out only person and role objects, so the organisation's name and country still come in the same answer.
ARIN and LACNIC are unchanged.
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.
in prod it's failing a lot (20-30%) and the backoff time is too big, it will never work through the backlog.
perhaps a maximum interval of 1 minute is appropriate, and the backoff should grow more slowly.
Plan:
AS<n>query returns them. So the RIPE queries change to the form RIPE documents for leaving those objects out (the-rflag), and the AS name, organisation and abuse address come from objects that do not count against the limit. Without this, a faster fetcher gets your host refused by RIPE sooner.A failed AS stays stale, and the next lookup picks a random stale AS, so one bad AS cannot hold up the rest.
Model: opus-5-5
Built in #167.
One change from the plan:
--no-personal, not-r. It leaves out only person and role objects, so the organisation's name and country still come in the same answer.ARIN and LACNIC are unchanged.
Model: opus-5-5