fix(atlas): a place that moves no longer keeps its old country (#2527)

place_regions caches the country and region Atlas resolved for a place,
and a row that was already there was never re-derived. Correcting a
place's location in the trip left the old row in charge, so Atlas, the
dashboard stats and the journey stats kept counting the country the place
had just left, with the trip's dates on it.

A trigger on places now drops the cached row whenever lat, lng or address
actually change, so every writer is covered: the place editor, the MCP
update tools, the plugin RPC and the import enrichment and address
backfill. An edit that writes the same location back keeps the row.

The background lookup that fills the cache also only writes while the
place still sits where it was resolved from. A place moved while its
lookup was running would otherwise get the old answer written back.

Places corrected before this fix would have kept their old country until
they were moved again, because the trigger only sees new edits.
PlaceRegionsRepairJob goes over place_regions once, on the first start
after the update, and remembers that in app_settings. It re-derives each
row from the bundled borders only, never Nominatim, and replaces a row
whose country or region no longer matches where its place is now. A row
the bundle cannot answer for is left alone unless both the coordinates
and the address put the place in another country; then it is dropped and
the next Atlas load looks the place up again. A place without
coordinates keeps no row. Its writes are guarded the same way as the
background lookup, so a place edited during the pass is not overwritten.

The in-memory region cache is now keyed by the country the address names
as well as the coordinates, so correcting only the address of a border
point no longer returns the old answer until a restart.

On dev the trigger takes schema version 244, the slot it has on main, so a
4.3.3 install upgrading to 4.4.0 does not skip it. Web Push moves up to
245 and is idempotent, so a 4.3.3 install gets its table there. An
instance that already ran Web Push at 244 never runs 244 again, so 246
creates the trigger once more; everywhere else that is a no-op.

server/src/db/migrations.ts

@@ -70,6 +70,22 @@ export function trimUserWhitespace(db: Database.Database): boolean {
   return hadCollision;
 }
 
+/**
+ * Keeps place_regions in step with the place it was resolved from (#2527): a
+ * change to lat, lng or address drops the cached row. Migrations 244 and 246
+ * both create it, see there.
+ */
+function createPlaceRegionsFollowPlaceTrigger(db: Database.Database): void {
+  db.exec(`
+    CREATE TRIGGER IF NOT EXISTS trg_place_regions_follow_place
+    AFTER UPDATE OF lat, lng, address ON places
+    WHEN OLD.lat IS NOT NEW.lat OR OLD.lng IS NOT NEW.lng OR OLD.address IS NOT NEW.address
+    BEGIN
+      DELETE FROM place_regions WHERE place_id = NEW.id;
+    END
+  `);
+}
+
 function runMigrations(db: Database.Database): void {
   db.exec('CREATE TABLE IF NOT EXISTS schema_version (version INTEGER NOT NULL)');
   const versionRow = db.prepare('SELECT version FROM schema_version').get() as { version: number } | undefined;
@@ -5258,6 +5274,27 @@ function runMigrations(db: Database.Database): void {
       }
     },
 
+    /*
+     * A place that moves takes its Atlas country with it (#2527).
+     *
+     * place_regions caches the country and region Atlas resolved from a
+     * place's coordinates and address, and nothing re-derives a row that is
+     * already there. Correcting a place's location left the old row in charge,
+     * so Atlas, the dashboard stats and the journey stats kept counting the
+     * country the place had just left.
+     *
+     * A trigger rather than a delete in the places code, because the row is
+     * derived from the place and every writer of lat, lng or address has to
+     * let go of it: the place editor, update_place, the plugin RPC, the import
+     * enrichment and its address backfill, and whatever comes next. The WHEN
+     * clause matters because every place edit writes lat, lng and address
+     * back whether they changed or not, and renaming a place must not throw
+     * away a good row. The next Atlas load resolves the place where it is now.
+     *
+     * This is 244 on main (4.3.3) as well, so it sits here, ahead of Web Push.
+     */
+    () => createPlaceRegionsFollowPlaceTrigger(db),
+
     /*
      * Web Push (#894): one row per browser a user switched push on in.
      *
@@ -5269,6 +5306,10 @@ function runMigrations(db: Database.Database): void {
      * up, rather than as a push service refusing every message. failure_count
      * and last_success_at are bookkeeping for the sender; the rows go with the
      * user.
+     *
+     * Web Push was 244 before the #2527 trigger took that slot to match main.
+     * A 4.3.3 install is already at 244 with the trigger and gets the table
+     * here; an instance that ran this at 244 replays it as a no-op.
      */
     () => {
       db.exec(`
@@ -5287,6 +5328,14 @@ function runMigrations(db: Database.Database): void {
         CREATE INDEX IF NOT EXISTS idx_push_subscriptions_user ON push_subscriptions(user_id);
       `);
     },
+
+    /*
+     * The #2527 trigger once more, for an instance that ran Web Push at 244
+     * before the trigger took that slot. Such an instance never runs 244 again,
+     * so it gets the trigger here. Everywhere else it already exists and this
+     * is a no-op.
+     */
+    () => createPlaceRegionsFollowPlaceTrigger(db),
   ];
 
   if (currentVersion < migrations.length) {