The IP lookup put every failed database read into the answer's errors, as if the address had no route. A disk error, or the out-of-memory error from the SQLite heap limit, therefore answered 404 "No routes found", or 200 next to a routed address, and the request log never counted it as a server error.
Now only a missing route or an invalid address goes into errors. Any other read error is logged with the address and answers 500 with the JSON error body and the fixed Internal server error message from #108, as the AS and prefix JSON routes already do. The time-limit check still comes right after the read, so a read cut off by the time limit still answers 504. lookupErrorMessage is removed because the loop now does its job.
What the diff does not show: when several addresses are looked up and one read fails, the whole answer is 500, including addresses already found, and no WHOIS refresh is queued for them. A 504 already behaves the same way.
Tests: TestIPLookupAnswers500WhenDatabaseReadFails covers a failing address on its own, a failing address with a routed one, and an address with no route (still 404). TestJSONRoutesDoNotSendErrorDetails now expects 500 for the IP route.
Judgement call: the error check is a switch and the response literal is on one line. This keeps handleIPInfo within the linter's limits (cognitive complexity 30, 80 lines) without moving code out of it.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/routewatch/issues/109.
The IP lookup put every failed database read into the answer's `errors`, as if the address had no route. A disk error, or the out-of-memory error from the SQLite heap limit, therefore answered 404 "No routes found", or 200 next to a routed address, and the request log never counted it as a server error.
Now only a missing route or an invalid address goes into `errors`. Any other read error is logged with the address and answers 500 with the JSON error body and the fixed `Internal server error` message from https://git.eeqj.de/sneak/routewatch/issues/108, as the AS and prefix JSON routes already do. The time-limit check still comes right after the read, so a read cut off by the time limit still answers 504. `lookupErrorMessage` is removed because the loop now does its job.
What the diff does not show: when several addresses are looked up and one read fails, the whole answer is 500, including addresses already found, and no WHOIS refresh is queued for them. A 504 already behaves the same way.
Tests: `TestIPLookupAnswers500WhenDatabaseReadFails` covers a failing address on its own, a failing address with a routed one, and an address with no route (still 404). `TestJSONRoutesDoNotSendErrorDetails` now expects 500 for the IP route.
- Judgement call: the error check is a `switch` and the `response` literal is on one line. This keeps `handleIPInfo` within the linter's limits (cognitive complexity 30, 80 lines) without moving code out of it.
Model: opus-5-5
A failed database read for an address was listed in the answer's errors
as if the address had no route, so the lookup answered 404, or 200 next
to a routed address. Only a missing route or an invalid address is
listed now; any other read error is logged and answers 500 with the JSON
error body, as the AS and prefix JSON routes do.
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.
Fixes #109.
The IP lookup put every failed database read into the answer's
errors, as if the address had no route. A disk error, or the out-of-memory error from the SQLite heap limit, therefore answered 404 "No routes found", or 200 next to a routed address, and the request log never counted it as a server error.Now only a missing route or an invalid address goes into
errors. Any other read error is logged with the address and answers 500 with the JSON error body and the fixedInternal server errormessage from #108, as the AS and prefix JSON routes already do. The time-limit check still comes right after the read, so a read cut off by the time limit still answers 504.lookupErrorMessageis removed because the loop now does its job.What the diff does not show: when several addresses are looked up and one read fails, the whole answer is 500, including addresses already found, and no WHOIS refresh is queued for them. A 504 already behaves the same way.
Tests:
TestIPLookupAnswers500WhenDatabaseReadFailscovers a failing address on its own, a failing address with a routed one, and an address with no route (still 404).TestJSONRoutesDoNotSendErrorDetailsnow expects 500 for the IP route.switchand theresponseliteral is on one line. This keepshandleIPInfowithin the linter's limits (cognitive complexity 30, 80 lines) without moving code out of it.Model: opus-5-5
Review passed.
Model: opus-5-5