fix(geo): ask ipinfo.io first, because ipwho.is puts some addresses in the wrong country - #4
Merged
Conversation
…n the wrong country ipwho.is is not merely imprecise on some networks, it is wrong by hundreds of kilometres and consistently so. A Virgin Media address in Ballymena, Northern Ireland resolves to Wakefield, England -- roughly 350km away, across the Irish Sea and in the wrong country of the UK. It reproduces on every request rather than intermittently, so auto-detection silently reports another country's weather with no hint anything is wrong. Checked against the same address at the same moment: ipwho.is Wakefield, England ~350km out ip-api.com Islington, England ~500km out ipinfo.io Ballymena, N. Ireland correct ipinfo.io answers first and ipwho.is is kept as a fallback rather than removed, so a provider being unreachable still yields a location instead of dropping auto-detection entirely. ipinfo.io's shape differs: there is no success flag, and coordinates come as one "lat,lon" string rather than two numbers, hence the separate response type and the split helper. `country` is already a two-letter code, so it feeds the same build_display_name slot as ipwho.is's country_code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0135HMddrDPNMpBCpVeS8nDs
- Coordinates from `loc` must be finite and within ±90/±180; a bad pair is an error, so the fallback runs instead of a request with NaN. - A non-2xx status is an error (`error_for_status`), a blank city too. - When both providers fail the message names each one with its error. - `ipinfo_location` is the pure half, with unit tests over real shapes (429, bogon, blank city, malformed loc).
Owner
|
Merged, thanks! Released in 0.5.4. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
ipwho.isis not merely imprecise on some networks — it is wrong by hundreds of kilometres, and consistently so.A Virgin Media address in Ballymena, Northern Ireland resolves to Wakefield, England: roughly 350km away, across the Irish Sea, and in the wrong country of the UK. It reproduces on every request rather than intermittently, so
--location autosilently reports another country's weather with nothing to suggest anything is wrong. On a laptop that moves between networks this is easy to miss, because the number looks perfectly plausible.Evidence
Same address, same moment:
ipwho.is(current)ip-api.comipinfo.ioThe change
ipinfo.iois asked first, andipwho.isis kept as a fallback rather than removed — a provider being unreachable then still yields a location instead of dropping auto-detection entirely.ipinfo.io's response shape differs in two ways, hence the separate type and the small helper:successflag — failure is an HTTP error, or a body with noloc"lat,lon"string rather than two numberscountryis already a two-letter code, so it feeds the samebuild_display_nameslot asipwho.is'scountry_codeand the display name format is unchanged.Testing
cargo test— 89 pass, 0 failcargo clippy— no new warnings (the two existing ones are inwaybar.rsandmain.rs, untouched here)cargo fmt --check— clean forapi.rs--location autoreturnedWakefield, England, GBbefore andBallymena, Northern Ireland, GBafterOne gotcha worth mentioning for anyone reproducing this: the 60s response cache is keyed on the requested location, so
autohits the cache before geolocation runs. Clear~/.cache/meteobar/between runs or the old provider's answer is served back and it looks like nothing changed.🤖 Generated with Claude Code