Problem
Migration 00009_contract_address.sql defaults existing rows to 0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d (the NEW contract). But all existing data (QA Test Story, ratings, donations, etc.) was created on the OLD contract 0x05c4d59529807316d6fa09cdaa509addfe85b474.
This means old data still shows on the frontend because the filter matches the current STORY_FACTORY address.
Fix
Create migration 00012_fix_contract_address_backfill.sql:
-- Re-tag all existing data to the old contract address
-- These rows were created before the contract was redeployed in PR #221
UPDATE storylines SET contract_address = '0x05c4d59529807316d6fa09cdaa509addfe85b474' WHERE contract_address = '0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d';
UPDATE plots SET contract_address = '0x05c4d59529807316d6fa09cdaa509addfe85b474' WHERE contract_address = '0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d';
UPDATE donations SET contract_address = '0x05c4d59529807316d6fa09cdaa509addfe85b474' WHERE contract_address = '0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d';
UPDATE ratings SET contract_address = '0x05c4d59529807316d6fa09cdaa509addfe85b474' WHERE contract_address = '0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d';
UPDATE comments SET contract_address = '0x05c4d59529807316d6fa09cdaa509addfe85b474' WHERE contract_address = '0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d';
UPDATE page_views SET contract_address = '0x05c4d59529807316d6fa09cdaa509addfe85b474' WHERE contract_address = '0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d';
Important: This is safe because no new data has been indexed on the new contract yet — any rows with the new address are old data that was incorrectly tagged.
Operator must also run this SQL manually against Supabase to fix production data immediately.
Files
supabase/migrations/00012_fix_contract_address_backfill.sql (new file)
Acceptance Criteria
Problem
Migration
00009_contract_address.sqldefaults existing rows to0x6b8d38af1773dd162ebc6f4a8eb923f3c669605d(the NEW contract). But all existing data (QA Test Story, ratings, donations, etc.) was created on the OLD contract0x05c4d59529807316d6fa09cdaa509addfe85b474.This means old data still shows on the frontend because the filter matches the current
STORY_FACTORYaddress.Fix
Create migration
00012_fix_contract_address_backfill.sql:Important: This is safe because no new data has been indexed on the new contract yet — any rows with the new address are old data that was incorrectly tagged.
Operator must also run this SQL manually against Supabase to fix production data immediately.
Files
supabase/migrations/00012_fix_contract_address_backfill.sql(new file)Acceptance Criteria