fix: ipapi.co stopped answering, so the lookup never resolved

Turning IP Geolocation on changed nothing: every lookup failed, and the
tool output still said "no Location is set in preferences", which is a
different problem and sent the user looking in the wrong place.

ipapi.co no longer serves an unauthenticated caller. Verified directly:

  no User-Agent    -> HTTP 429 {"reason":"RateLimited",
                                 "message":"Please sign up for a paid plan"}
  browser UA       -> HTTP 403, a Cloudflare "Just a moment..." challenge

So the provider is now ipwho.is, which answers 200 without a key. It
signals refusal with success: false on an HTTP 200, so the body is checked
as well as the status, and it nests the timezone under an object, which the
parser now accepts alongside a bare string. A named User-Agent is sent:
node's default is bare, and "who is asking" is the one thing a geolocation
provider has a fair interest in.

The failure branch is also fixed. A failed lookup and an unset preference
are different problems, and the wording no longer conflates them. The note
tells the model to pass the failure on, because the model is the only
channel that reaches the user and it had been paraphrasing the failure away.

Accuracy is documented honestly rather than as "city-level". An IP locates
the ISP's egress, not the person: measured from one machine, an IPv4 query
resolved to Cebu City and an IPv6 query moments later to Talisay in
Calabarzon, about 500km apart. That is now in the README, the preference
description and the tool output, and it is the argument for setting
Location instead.

Verified live with the exact request and field access the extension uses:
HTTP 200, "Talisay, Calabarzon (Region IV-A), Philippines", Asia/Manila.
344 tests, tsc, eslint, prettier, and vici build.
This commit is contained in:
2026-10-04 15:59:09 +08:00
parent 51c16b678f
commit af325b4a62
7 changed files with 102 additions and 39 deletions
+32 -12
View File
@@ -11,6 +11,13 @@ import { errorMessage } from "./utils";
* skipped entirely when the user has already said where they are, and the tool
* output names the provider so the model can qualify what it repeats.
*
* How accurate is it? Less than the name suggests, and the honest answer is that
* an IP address locates the point where the traffic left the ISP, not the person.
* Measured from one machine on Globe Telecom, an IPv4 query resolved to Cebu City
* and an IPv6 query, moments later, to Talisay in Calabarzon: about 500km apart.
* The cache is therefore not just a privacy measure, and the tool output calls
* the result a rough guess rather than a city.
*
* The answer is cached for hours rather than looked up per call. A city does not
* change between questions, and every lookup hands the provider another copy of
* the user's IP address.
@@ -21,8 +28,8 @@ import { errorMessage } from "./utils";
*/
/** Where the lookup goes. Swapping providers means changing this and the parser below. */
export const GEO_PROVIDER = "https://ipapi.co/json/";
export const GEO_PROVIDER_NAME = "ipapi.co";
export const GEO_PROVIDER = "https://ipwho.is/";
export const GEO_PROVIDER_NAME = "ipwho.is";
/** How long a resolved place is trusted. Long enough to not re-leak the IP on every question. */
export const GEO_TTL_MS = 6 * 60 * 60 * 1000;
@@ -68,17 +75,20 @@ const CachedSchema = z.object({
fetchedAt: z.number(),
});
/** The subset of ipapi.co's response this needs, with every field optional so a shape change degrades instead of throwing. */
/** The subset of the provider's response this needs, with every field optional so a shape change degrades instead of throwing. */
const ResponseSchema = z.object({
error: z.unknown().optional(),
reason: z.string().optional(),
success: z.boolean().optional(),
message: z.string().optional(),
city: z.string().nullable().optional(),
region: z.string().nullable().optional(),
country_name: z.string().nullable().optional(),
country: z.string().nullable().optional(),
latitude: z.number().nullable().optional(),
longitude: z.number().nullable().optional(),
timezone: z.string().nullable().optional(),
// ipwho.is nests the timezone; some providers hand back a plain string.
timezone: z
.union([z.string(), z.object({ id: z.string().optional() })])
.nullable()
.optional(),
});
/**
@@ -117,7 +127,15 @@ async function fetchWithTimeout(
signal?.addEventListener("abort", forward, { once: true });
try {
return await fetch(url, { signal: controller.signal, headers: { Accept: "application/json" } });
return await fetch(url, {
signal: controller.signal,
headers: {
Accept: "application/json",
// Named rather than anonymous. Node's default UA is bare, and "who is
// asking" is the one thing a geolocation provider has a fair interest in.
"User-Agent": "lam-agent-vicinae",
},
});
} finally {
clearTimeout(timer);
signal?.removeEventListener("abort", forward);
@@ -182,22 +200,24 @@ export async function ipPlace(options: GeoOptions = {}): Promise<GeoLookup> {
}
const data = parsed.data;
if (data.error) {
if (data.success === false) {
return {
status: "failed",
message: data.message ?? data.reason ?? `${GEO_PROVIDER_NAME} refused the lookup`,
message: data.message ?? `${GEO_PROVIDER_NAME} refused the lookup`,
};
}
const city = data.city ?? undefined;
const region = data.region ?? undefined;
const country = data.country_name ?? undefined;
const country = data.country ?? undefined;
const place = buildPlace({ city, region, country });
if (!place) {
return { status: "failed", message: `${GEO_PROVIDER_NAME} returned no usable place` };
}
const timezone = typeof data.timezone === "string" ? data.timezone : data.timezone?.id;
const resolved: GeoPlace = {
place,
city,
@@ -205,7 +225,7 @@ export async function ipPlace(options: GeoOptions = {}): Promise<GeoLookup> {
country,
latitude: data.latitude ?? undefined,
longitude: data.longitude ?? undefined,
timezone: data.timezone ?? undefined,
timezone: timezone ?? undefined,
source: GEO_PROVIDER_NAME,
fetchedAt: now,
};