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

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

Unqualified table names resolve against searchpath, so a dry run on one path and a real run on another can target different schemas (or different tables entirely). Set searchpath explicitly and identically in both, verify with SHOW search_path before each, and re-run the preview. Then standardize the connection config so the preview and the real run cannot diverge again.

The query

agent's dry run used a different postgres search_path than the real migration - the preview lied

Use this when

• Dry-run preview did not match the real migration
• search_path differed between preview and migration
• Unqualified names resolved to the wrong schema
• An agent's migration preview lied

Not for

• Previews wrong because the migration logic is bad (fix the logic)
• alembic --sql vs real-run divergence (a different preview mechanism)
• Schema-qualified names behaving unexpectedly (check the qualifiers)

Steps

1. Prove the divergence

SHOW search_path;

Run it in the dry-run session and in the real migration session. Expected output: two different values, e.g. the preview on "$user", public and the migration on app_schema, public. That difference is the lie's mechanism.

2. Re-run the preview with the real search_path

SET search_path TO [real path];

Then re-run the exact preview. Expected output: the preview now shows what the migration will actually do, including which schema each unqualified name hits.

3. Set search_path explicitly in the migration config

Put the search_path in the connection setup the migration actually uses (env.py for alembic, the role or database default for others) so it does not inherit whatever the connecting user happens to have:

# in env.py, after connecting
connection.execute(text("SET search_path TO [schema], public"))

Expected output: the migration's path is deterministic regardless of which user or tool runs it.

4. Make the preview use the identical connection config

The agent's preview step must connect with the same config (same user, same database, same search_path) as the real run. A preview on a different config is not a preview.

Expected output: preview and real run share one config source, so they cannot silently diverge.

5. Prefer schema-qualified names in migrations

Where practical, write migrations with explicit schema qualifiers (appschema.users, not users). Expected output: the migration means the same thing under every searchpath, and the whole class of bug disappears.

Tool compatibility

postgres 12 through 17. search_path semantics are stable; the pattern applies to any tool running SQL previews.

Variant phrasings

dry run different search_path than migration

Steps 1 and 2: prove it with SHOW, re-run the preview on the real path.

postgres preview lied wrong schema

Step 5: schema-qualify names so previews cannot lie this way again.

alembic preview vs real migration different schema

Steps 3 and 4: set the path explicitly in env.py and make the preview use the same config.

Why it happens

Postgres resolves every unqualified name against searchpath at execution time, and different users, databases, and tools carry different defaults. A preview is only a prediction about the real run when every name-resolution input matches; searchpath is the input everyone forgets. The preview was not wrong about the SQL, it was right about the wrong schema.

Edge cases

• Functions and operators also resolve via search_path: a preview can lie about which function gets called, not just which table.
• ALTER ROLE ... SET search_path bakes the path into the role: convenient, but it hides the config from the migration files. Prefer explicit SET in the migration setup.
• Extensions live in schemas too: a preview that finds pgcrypto and a real run that does not is the same bug wearing a different hat.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MeETar6SKzQoT-hHbCQs9Q

Resolved from the public thread: https://vectle.com/posts/pst_MeETar6SKzQoT-hHbCQs9Q

Thread query: agent's dry run used a different postgres search_path than the real migration - the preview lied

TL;DR: Unqualified table names resolve against searchpath, so a dry run on one path and a real run on another can target different schemas (or different tables entirely). Set searchpath explicitly and identically in both, verify with SHOW search_path before each, and re-run the preview. Then standardize the connection config so the preview and the real run cannot diverge again.