feat(remote): re-dump production statistics on a daily floor

[veksen]

Closes Query-Doctor/Site#3671.

Goal

Bound how stale a snapshot's column statistics can get when neither drift signal fires.

What

Before, a snapshot refreshed only on Shape Drift or Size Drift. A database whose tables and sizes hold steady never re-dumped, however old its statistics got.

After, a connected analyzer re-dumps at least once every 24 hours.

How

isPastRefreshFloor in stats-drift.ts is the decision, kept pure and beside the drift signals. Remote records when it last pushed, and the existing schema-poll check now fires on drift or the floor. No new schedule.

Two properties worth noting:

• A push from either trigger updates the timestamp, so drift and the floor can't dump twice in quick succession.
• The floor never fires before a first push. With no baseline there is nothing to compare against, and dumping on a timer for an analyzer that has never pushed would publish statistics for a database the server may not expect.

Departure from the ADR

ADR 0007 §2 specifies this backstop as a cron in Site. It sits in the analyzer here. The server currently has no way to ask an analyzer to refresh, so the Site-side version needs a new ClientApi method, an analyzer implementation, and a cron, where this needs one timestamp. If the Site placement is preferred, amend the ADR rather than leaving the two out of step.

Tests

Five cases in stats-drift.test.ts: never before a first push, not while recent, true at exactly a day, true well past, and a custom floor honoured in both directions.

[github-actions]

Query Doctor Analysis

3 queries analyzed

0 regressed · 0 improved · 0 new · 0 removed

2 pre-existing issues

• SELECT "guests"."id", "guests"."session_id", "guests"."username", "guests"."avatar_path", "guests"."color", "guests"."side", "guests"."audio_recording_path", "guests"."audio_recording_public", "gue...
  index assets(event_id, inserted_at desc)
  cost 31,003,449 → 1,498 (100% reduction)
• SELECT * FROM guest_ip_addresses WHERE ip_address = '127.0.0.1';
  index guest_ip_addresses(ip_address)
  cost 154,402 → 8 (100% reduction)

_{Using assumed statistics (10000000 rows/table). For better results, sync production stats.}

_{More detail → get_ci_run({ runId: "019fa558-4f0f-749a-ba4c-c3b66a738f07" }) · view run · docs}

[veksen]

Review found the floor never fires for the analyzers it targets. Fixed in 072ebe8.

lastStatsPushAt is written only by applyStatistics, and the sync path (onSuccessfulSync) calls optimizer.start directly instead. So a seeded analyzer left it undefined and isPastRefreshFloor short-circuited forever — only a drift-triggered dump ever armed it, which is exactly the case the floor is meant to cover when drift doesn't fire. It also reset on every process restart.

Seeding now arms it, dated from the seed rather than the snapshot's capture time, which getProductionStats doesn't carry. The floor fires 24h after connect rather than immediately.

Also fixed: a failing dump retried on every 60s poll, since the timestamp only advances on success. A statement_timeout on a large pg_statistic read would have run DUMP_STATS_SQL about 1440 times a day. Failures now back off 15 minutes.

Two findings left for a follow-up, both pre-existing and wider than this PR:

• applyStatistics keys on statsMode.kind === "fromStatisticsExport" to decide whether stats are source-derived, but statsModeFromExport returns that kind for imports too. So a recurring import advances the floor timer without a source dump, and resetStats (which is fromAssumption) clears neither the baseline nor the timer. The comment above that check already describes the intent the discriminator doesn't implement.
• No integration coverage for the refresh path in remote.test.ts. The findings above were all invisible to the suite.