V61: UUID Column Safety Net for Tables Missed by V40
Root Cause
V40 adds a uuid column to 33 legacy tables, but uses repo().query()
for its table_exists? checks. In Ecto migrations, repo().query() is
executed immediately against the database, while migration commands
(execute, create, alter) are buffered until flush() or
callback return.
During a fresh install (V01→V49 in one Ecto migration), V31 calls
flush() — making V01–V31 tables visible — but V32–V39 tables remain
buffered when V40 runs. V40 therefore skips all V32+ tables.
V56 added a safety net for 6 of these tables:
- consent_logs, payment_methods, ai_endpoints, ai_prompts, sync_connections, subscription_plans
This migration covers the remaining 6 tables that V40 missed and V56 did not catch:
Tables Fixed
| Table | Created in | Why missed |
|---|---|---|
phoenix_kit_admin_notes | V39 | After V31 flush, before V40 |
phoenix_kit_ai_requests | V32 | After V31 flush, before V40 |
phoenix_kit_subscriptions | V33 | After V31 flush, before V40 |
phoenix_kit_payment_provider_configs | V33 | After V31 flush, before V40 |
phoenix_kit_webhook_events | V33 | After V31 flush, before V40 |
phoenix_kit_sync_transfers | V37/V44 | After V31 flush, before V40 |
Additional Fix
Adds created_by_uuid FK column to phoenix_kit_scheduled_jobs (V42).
This table uses a UUID native PK so it doesn't need a uuid identity
column, but its created_by_id integer FK was missing its UUID companion.
Permanent Fix
V40 has been updated with flush() at the start of up() so this
issue cannot recur on new installations.
All operations are idempotent — safe to run on any installation.