Freeze pantheon community race leaderboard snapshot

[owens1127]

Summary

• Add leaderboard.pantheon_custom_race_snapshot with 110 seeded instance IDs (frozen prod LB as of 2026-06-30).
• Drop team_pantheon_custom_race_leaderboard MV (phased — see rollout).
• Point cheat-detection cascade join at snapshot table.
• Remove pantheon custom race MV refresh cron + Tiltfile entry.

Companion: Raid-Hub/API#150

Prod rollout (no downtime)

Apply 012_pantheon_custom_race_snapshot.sql in two phases — do not run the full file at once on prod.

Phase 1 — before API deploy

Run the Phase 1 section only (CREATE TABLE + INSERT). Current API keeps reading the MV.

-- Verify: SELECT COUNT(*) FROM leaderboard.pantheon_custom_race_snapshot; -- expect 110

Phase 2 — merge + deploy API first

Merge and deploy Raid-Hub/API#150. API reads pantheon_custom_race_snapshot with fallback to the legacy MV.

Smoke test:

curl -s "https://api.raidhub.io/leaderboard/team/custom/pantheon-community-race?page=1&count=5" | jq '.entries | length'

Phase 3 — after API deploy

Run the Phase 2 section (DROP MATERIALIZED VIEW). Merge this PR and update prod cron (remove pantheon refresh line).

Phase 4 — blacklist cleanup

Dry-run first:

SELECT COUNT(*) FROM flagging.blacklist_instance bi
WHERE bi.report_source = 'Manual'
  AND bi.instance_id NOT IN (SELECT instance_id FROM leaderboard.pantheon_custom_race_snapshot)
  AND bi.reason NOT ILIKE '%cheat%'
  AND bi.reason NOT ILIKE '%cheater%'
  AND EXISTS (
    SELECT 1 FROM core.instance i
    JOIN definitions.activity_version av ON av.hash = i.hash
    WHERE i.instance_id = bi.instance_id
      AND av.version_id = 134
      AND i.date_completed >= '2026-06-13 17:00:00+00'::timestamptz
      AND i.date_completed < '2026-06-15 17:00:00+00'::timestamptz
  );

Expected ~52 rows. Then apply:

BEGIN;
DELETE FROM flagging.blacklist_instance bi
WHERE bi.report_source = 'Manual'
  AND bi.instance_id NOT IN (SELECT instance_id FROM leaderboard.pantheon_custom_race_snapshot)
  AND bi.reason NOT ILIKE '%cheat%'
  AND bi.reason NOT ILIKE '%cheater%'
  AND EXISTS (
    SELECT 1 FROM core.instance i
    JOIN definitions.activity_version av ON av.hash = i.hash
    WHERE i.instance_id = bi.instance_id
      AND av.version_id = 134
      AND i.date_completed >= '2026-06-13 17:00:00+00'::timestamptz
      AND i.date_completed < '2026-06-15 17:00:00+00'::timestamptz
  );
COMMIT;

Test plan

• go build ./...
• CI migrate + seed passes with full 012 on fresh DB

Made with Cursor

[owens1127]

Superseded by the new PR that seeds the snapshot via INSERT SELECT from the MV instead of hardcoded rows. Prod rollout already applied manually.

[sentry]

Bug: The query in BlacklistRecentInstances joins pantheon_custom_race_snapshot without checking if the table exists, which can cause a crash if deployed before the database migration.
_{Severity: CRITICAL}

Suggested Fix

Implement a fallback mechanism or conditional logic in the Go code to handle cases where the pantheon_custom_race_snapshot table does not yet exist. This would prevent the service from crashing if there is a delay in running the database migration. Alternatively, ensure deployment tooling strictly enforces that the migration runs before the code is active.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: lib/services/cheat_detection/database_layer.go#L265

Potential issue: The `BlacklistRecentInstances()` function in `database_layer.go`
performs a `LEFT JOIN` on the new `pantheon_custom_race_snapshot` table. The code does
not include any fallback logic or check for the table's existence. If this code is
deployed before the corresponding database migration creating the table has been run,
any call to this function will cause the cheat detection service to crash with a
"relation does not exist" error. The multi-phase rollout described for this change
increases the risk of this deployment sequencing issue occurring.

_{Did we get this right? 👍 / 👎 to inform future reviews.}