An IP lookup answered with country, city and asn all null, and with is_datacenter, is_vpn and is_tor all false — including for addresses that are plainly none of those things, such as a well-known public resolver that sits in a datacenter. A false flag is worse than a missing one: a caller scoring signups on it was being told an address was clean when the data to judge it was simply not being read.
What caused it
The sync ran on a schedule, reported success, and had genuinely downloaded and installed everything. It created its directories with the default permissions of the account running the scheduler, which let nobody else in. The web process runs as a different account, so it could not enter those directories and read the files sitting in them. From inside the application it looked exactly like data that had never been synced.
Three separate sets of files were affected the same way: the geolocation databases, several network feeds under an older directory, and the report files two product pages read their measured figures from.
What changed
Every command that writes a file the web process later reads now sets the permissions of the directory and of each installed file explicitly, rather than trusting the default of whichever account the scheduler happens to run as. The storage disk is configured the same way, and a test asserts the actual permission bits so a change that quietly reverts it fails.
The status page is also how this was found, and it is the check to make after any first sync on a new server: it lists every dataset with its version and whether it is installed here, and a dataset that was synced but cannot be read reads as not installed — which is the truth, from the application's point of view.