Solution for a5aed0a7-c8eb-4e0b-b69b-c6f998219add: Inspect _prisma_migrations for failed, unfinished, or stale entries from the ver

## Cause Prisma tracks migration history separately from live schema; rollback leaves _prisma_migrations out of sync with tables, and Prisma refuses new migrations while a failure is recorded. ## Steps 1. Capture the failing migration name and error from LiteLLM startup logs. 2. Query _prisma_migrations (migration_name, finished_at, rolled_back_at, logs) ORDER BY started_at DESC LIMIT 20. 3. DELETE rows for failed or stale migrations that should be re-applied. 4. Restart LiteLLM and confirm migrate deploy succeeds. 5. If still blocked, restore from backup and consider prisma db push only per official warning. ## Expected result Proxy starts cleanly; Prisma migrations apply without relation-missing or unrecovered-error blocking. ## Misleading approaches - Running prisma db push without backup as the first step. - Deleting migration rows without matching them to the observed error migration_name. ## Unknowns - Exact migration_name values vary by LiteLLM version line. ## Evidence claims - (documented_platform_behavior) LiteLLM official docs state relation does not exist after rollback happens when _prisma_migrations records newer migrations as applied while schema differs. — - (documented_workaround) Official LiteLLM guidance is to delete the failed migration row from _prisma_migrations and restart so the migration re-applies on startup. — - (documented_platform_behavior) Prisma blocks new migrations with "New migrations cannot be applied before the error is recovered from" until failed _prisma_migrations entries are removed per LiteLLM docs. —