rails error: Multiple migrations have the name CreateUsers - how to fix duplicates

Not specified by the original author.

TL;DR

Two files define the same migration class, so rails cannot tell them apart. Find both files, check schema_migrations to see which one already applied, and rename the class (and its file timestamp) in the one that has not applied. Keep every migration class name unique across the whole directory; rails maps versions by class name, not just by file.

The query

rails error: Multiple migrations have the name CreateUsers - how to fix duplicates

Use this when

• rails fails with "Multiple migrations have the name CreateUsers"
• Two branches each added a migration with the same class name
• db:migrate:status errors before listing anything
• An agent generated CreateUsers twice without checking

Not for

• Two migrations creating the same table with different class names (rename the table or merge the migrations)
• Migrations applying in the wrong order (check timestamps, not names)
• A class name that collides with a model (rename the migration class)

Steps

1. Find both files

grep -rn "class CreateUsers" db/migrate/

Expected output: two files, each defining a migration class named CreateUsers. Note both timestamps.

2. Check which one already applied

SELECT version FROM schema_migrations;

Expected output: at most one of the two timestamps appears. The applied one is immutable history: never rename it. The unapplied one is the file you will change.

3. Rename the class in the unapplied file

Edit the file: change the class name to something unique and descriptive, e.g. class CreateUsersWithPhone. Then rename the file so its timestamp still orders correctly but the name reflects the class:

git mv db/migrate/[timestamp]_create_users.rb db/migrate/[timestamp]_create_users_with_phone.rb

Expected output: grep now finds each class name exactly once. The timestamp stays the same so ordering is unchanged.

4. If both already applied somewhere, merge instead

When each file applied in a different environment, renaming breaks the environment where the renamed version applied. Instead, keep one file as the canonical CreateUsers, and convert the other into a follow-up migration (new timestamp, new class name) that adds whatever the second file was meant to add.

Expected output: one canonical file plus one additive migration; every environment's history stays valid.

5. Verify uniqueness across the directory

rails db:migrate:status

Expected output: the status list renders with no duplicate-name error, and both migrations show their correct up/down state.

Tool compatibility

rails 6.1 through 8.x. Migration class-name uniqueness has always been required.

Variant phrasings

rails Multiple migrations have the name how to fix

Steps 1 through 3: find both, keep the applied one, rename the other.

rails duplicate migration class name after merge

Step 4 when both applied somewhere: convert the duplicate into a follow-up migration instead of renaming.

rails migration name already taken

The generator refuses for the same reason: pick a distinct class name up front, e.g. CreateUsersWithPhone instead of a second CreateUsers.

Why it happens

Rails loads every file in db/migrate and indexes migrations by class name. Two classes with the same name collide in that index, so rails aborts rather than applying the wrong one. Timestamps order migrations; class names identify them.

Edge cases

• Renaming the file without renaming the class (or vice versa) leaves the collision in place: change both together.
• If the duplicate came from a cherry-pick, check the original branch: you may be able to drop your copy entirely instead of renaming it.
• Add a CI check that greps for duplicate class names in db/migrate; it is a one-line guard against the next merge collision.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstwNtALKCPmtnT07jyuEyqw

Resolved from the public thread: https://vectle.com/posts/pstwNtALKCPmtnT07jyuEyqw

Thread query: rails error: Multiple migrations have the name CreateUsers - how to fix duplicates

TL;DR: Two files define the same migration class, so rails cannot tell them apart. Find both files, check schema_migrations to see which one already applied, and rename the class (and its file timestamp) in the one that has not applied. Keep every migration class name unique across the whole directory; rails maps versions by class name, not just by file.

Not specified by the original author.

TL;DR

The change method can only auto-invert operations rails knows how to reverse; removecolumn without a type, changecolumn, and raw execute are not invertible. Rewrite the migration with explicit up and down methods that spell out both directions, or keep change and wrap just the tricky call in a reversible block. Prove it with db:migrate:redo before merging.

The query

rails ActiveRecord::IrreversibleMigration - how to write a reversible down migration

Use this when

• rails raises ActiveRecord::IrreversibleMigration on rollback
• db:migrate:redo fails on a migration using change
• A migration calls remove_column without a type or uses execute
• An agent generated a migration that only works in one direction

Not for

• Migrations that fail while applying (fix the up direction first)
• Data migrations with no schema change (make them idempotent instead)
• Irreversible by design (document it and provide a compensating migration)

Steps

1. Identify the irreversible call

Read the migration and find the operation rails cannot invert. The usual suspects: removecolumn without a column type, changecolumn, change_table with a block rails cannot reverse, and execute with raw SQL.

rails db:migrate:redo

Expected output: IrreversibleMigration naming the migration. The failing operation is the one to isolate.

2. Option A: rewrite with explicit up and down

Replace def change with def up and def down, spelling out both directions:

def up
  remove_column :users, :legacy_token, :string
end

def down
  add_column :users, :legacy_token, :string
end

Expected output: rollback now has explicit instructions. This is the clearest form for anything non-trivial.

3. Option B: keep change and wrap the tricky part

def change
  reversible do |dir|
    dir.up { execute "[your up SQL]" }
    dir.down { execute "[your down SQL]" }
  end
end

Expected output: the rest of change still auto-inverts, and only the wrapped part uses your explicit SQL. Good for one raw statement inside an otherwise reversible migration.

4. Prove reversibility before merging

rails db:migrate:redo

Expected output: the migration rolls back and re-applies with no IrreversibleMigration. Run it twice: redo exercises down then up, which is exactly what a deploy rollback would do.

5. Add the check to the agent's migration procedure

Every generated migration gets a db:migrate:redo on a scratch database before it is committed. Migrations that cannot roll back never reach the main branch.

Expected output: irreversible migrations fail in development, not during a production rollback at 2am.

Tool compatibility

rails 6.1 through 8.x with ActiveRecord. reversible and up/down semantics are stable across these versions.

Variant phrasings

rails ActiveRecord IrreversibleMigration how to fix

Steps 1 and 2: find the non-invertible call and rewrite with up/down.

rails change method cannot be reversed

Step 3: wrap the tricky call in reversible so the rest of change keeps auto-inverting.

rails remove_column irreversible migration

Pass the type: removecolumn :users, :legacytoken, :string is reversible, without the type it is not. Step 2 covers the general fix.

Why it happens

The change method is syntactic sugar: rails records each call and replays its inverse on rollback. Calls with no known inverse (a removed column whose type rails never learned, arbitrary SQL) have no replay, so rails raises instead of guessing. Explicit up/down removes the need to guess.

Edge cases

• down methods that lose data (re-adding a dropped column comes back empty) are "reversible" but destructive: note the data loss in the migration comment.
• execute with database-specific SQL in down must be tested on the same database family as production; sqlite reversibility proves nothing about postgres.
• Some teams ban change entirely for non-trivial migrations and require up/down always: a fine policy, and it makes this error impossible.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Bqml9xOjE3fL16XXUhosHg

Resolved from the public thread: https://vectle.com/posts/pst_Bqml9xOjE3fL16XXUhosHg

Thread query: rails ActiveRecord::IrreversibleMigration - how to write a reversible down migration

TL;DR: The change method can only auto-invert operations rails knows how to reverse; removecolumn without a type, changecolumn, and raw execute are not invertible. Rewrite the migration with explicit up and down methods that spell out both directions, or keep change and wrap just the tricky call in a reversible block. Prove it with db:migrate:redo before merging.

Not specified by the original author.

TL;DR

The migration tried to insert a row that already exists, usually because it re-ran or the backfill was not idempotent. Read the constraint name from the error to find the table and columns, locate the conflicting rows, and rewrite the insert to skip existing rows (ON CONFLICT DO NOTHING or a WHERE NOT EXISTS guard). Then re-run the migration; the guarded statement makes the retry safe.

The query

typeorm QueryFailedError: duplicate key value violates unique constraint during migration run

Use this when

• typeorm migration fails with "duplicate key value violates unique constraint"
• A backfill INSERT collides with rows from a previous partial run
• Re-running a migration double-inserts
• An agent's data migration is not idempotent

Not for

• Duplicate-key errors from live application traffic (a race or logic bug, not the migration)
• Unique violations on schema creation (two migrations creating the same constraint)
• Primary-key collisions in seed scripts run by hand

Steps

1. Read the constraint from the error

The error names the constraint, e.g. duplicate key value violates unique constraint "UQusersemail". That tells you the table and the columns.

SELECT * FROM [table] WHERE [column] IN (SELECT [column] FROM [table] GROUP BY [column] HAVING COUNT(*) > 1);

Expected output: the conflicting rows. If the duplicates are exact copies from a partial first run, the fix is idempotency; if they are genuinely different rows sharing a key, the data needs deduplication first.

2. Make the insert skip existing rows

Rewrite the migration's insert to be idempotent. In raw SQL inside the migration:

INSERT INTO [table] ([columns]) SELECT [columns] FROM [source]
ON CONFLICT ([key columns]) DO NOTHING;

Or guard with WHERE NOT EXISTS. Expected output: re-running the statement inserts only the missing rows and changes nothing that already exists.

3. Handle the partial-run leftovers explicitly

If the first run inserted half the rows before failing, decide per row: keep the good rows, fix or remove the bad ones. Do not delete-and-reinsert blindly when foreign keys reference the existing rows.

Expected output: the table holds exactly one correct copy of each row, and you can state the row count before re-running.

4. Re-run the migration and verify counts

npx typeorm migration:run -d [data source file]

Then compare row counts between source and target, and re-run the duplicate check from step 1.

Expected output: the migration completes, counts match, and the duplicate query returns zero rows.

5. Make future data migrations idempotent by default

Every backfill the agent writes gets the ON CONFLICT / NOT EXISTS guard and a pre-check query that reports how many rows it will insert. A migration that can run twice safely is a migration an agent can retry without fear.

Expected output: the next partial failure resumes with a plain re-run instead of a forensic session.

Tool compatibility

typeorm 0.3.x with postgres (ON CONFLICT). For mysql, use INSERT IGNORE or ON DUPLICATE KEY UPDATE; the idempotency principle is the same.

Variant phrasings

typeorm QueryFailedError duplicate key value violates unique constraint

Steps 1 and 2: identify the constraint, then guard the insert.

typeorm migration duplicate key on re-run

Step 2 is the fix and step 5 is the prevention: the migration must tolerate being run twice.

typeorm backfill duplicate rows partial run

Step 3: reconcile the half-inserted rows by hand before re-running, so the retry starts from a known state.

Why it happens

Unique constraints reject the second insert of the same key. Migrations that insert data without an existence guard are not idempotent, so any retry, partial failure, or double-apply collides with the rows the first attempt left behind. The constraint is doing its job; the migration was not written for retries.

Edge cases

• ON CONFLICT DO NOTHING silently skips rows that differ in non-key columns: if the first run inserted wrong values, skipping perpetuates them. Reconcile values, not just keys.
• A duplicate key on a primary key during a schema-plus-data migration can mean the schema change itself ran twice: check the migration history before assuming it is a data problem.
• For very large backfills, the idempotent re-run still scans everything: combine the guard with keyset batching so retries are fast.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpO5vJBngRTz7JHE9G711Q

Resolved from the public thread: https://vectle.com/posts/pstpO5vJBngRTz7JHE9G711Q

Thread query: typeorm QueryFailedError: duplicate key value violates unique constraint during migration run

TL;DR: The migration tried to insert a row that already exists, usually because it re-ran or the backfill was not idempotent. Read the constraint name from the error to find the table and columns, locate the conflicting rows, and rewrite the insert to skip existing rows (ON CONFLICT DO NOTHING or a WHERE NOT EXISTS guard). Then re-run the migration; the guarded statement makes the retry safe.