Ecto 3.0 Concurrent Index Creation: Managing Failed Migrations and Manual Cleanup

Goal: Determine a reliable way to detect and remove a partially created index when a concurrent index migration fails in Ecto 3.0, so that the migration can be retried without leaving orphaned schema objects.

Constraints: Because Ecto disables the transaction wrapper for create_index/3 with concurrently: true, a failure does not trigger an automatic rollback, and long‑running write transactions on the table can block the index build, causing the migration to stall. There is no built‑in cleanup mechanism, leaving teams to decide how to identify orphaned indexes and drop them safely before retrying.

Specific questions:

• What is the recommended method to detect a partially created concurrent index after a migration error?
• How should a team safely drop such an index to avoid interfering with ongoing reads or writes?
• Are there any Ecto configuration options or migration helpers that can automate this cleanup?