django error: Migration auth.0012 dependencies reference nonexistent parent node

Not specified by the original author.

TL;DR

The migration's dependencies tuple names a parent file that is gone: deleted, renamed, or never merged. Open the file, read the broken tuple, find the app's real leaf with showmigrations, and edit the dependency to point at it. Then run migrate --plan to prove the graph resolves before applying anything.

The query

django error: Migration auth.0012 dependencies reference nonexistent parent node

Use this when

• django migrate fails with "dependencies reference nonexistent parent node"
• A migration file was deleted or renamed and a child still points at it
• After a squash, old children still reference pre-squash parents
• An agent hand-edited a dependencies tuple and typo'd the parent

Not for

• InconsistentMigrationHistory (ordering, not a missing file)
• Two live leaf nodes needing a merge migration (use makemigrations --merge)
• A database error inside a migration's operations (fix the operations)

Steps

1. Read the broken dependency tuple

Open the failing migration file and find its dependencies list. Note the app label and migration name it references, e.g. ("auth", "0012_something").

grep -n "dependencies" -A 5 [app]/migrations/0013_[name].py

Expected output: the exact tuple that does not resolve. This is the string you will replace.

2. Find the app's real leaf nodes

python manage.py showmigrations auth

Expected output: the list of migrations with [X] marks. The unapplied or latest migration at the tip of the graph is the parent this file should probably depend on. If there are two tips, you have a branch that needs a merge migration first.

3. Check version control for what happened to the parent

git log --diff-filter=D --name-only -- [app]/migrations/

Expected output: whether the parent was deleted (restore it or repoint) or renamed (repoint to the new name). A rename is the kindest case: the content still exists under a new filename.

4. Repoint the dependency at the real parent

Edit the dependencies tuple in the failing file to reference the actual leaf, e.g. ("auth", "0011realname"). Keep the tuple format exactly: a list of two-element tuples of strings.

Expected output: the file now references a migration that exists on disk.

5. Prove the graph resolves

python manage.py migrate --plan

Expected output: a clean plan with no "nonexistent parent node" error. On a scratch database, run the full migrate from zero to prove new environments bootstrap.

Tool compatibility

django 3.2 through 5.x. Migration graph resolution works the same across these versions.

Variant phrasings

django dependencies reference nonexistent parent node

Steps 1, 2, and 4: read the broken tuple, find the real leaf, repoint.

django migration parent does not exist after squash

Step 3: squashes rename the world. Repoint children at the squash migration, or keep the pre-squash files until every environment has passed the squash point.

django makemigrations nonexistent parent

The error fires at migrate time from the graph loader, not at makemigrations time: fix the tuple by hand as in step 4.

Why it happens

Django loads every migration file and links dependencies into a graph before planning. A dependency naming a file that is not on disk cannot be linked, so graph construction fails outright. The database is never touched; the error is purely about the file graph.

Edge cases

• Never "fix" this by creating an empty file with the old name unless the old migration's operations already applied everywhere: an empty parent silently drops schema work on fresh databases.
• If the missing parent applied in production under its old name, production's django_migrations still references it: restoring the file (even as a no-op guarded by history) is safer than repointing.
• Run makemigrations --check in CI to catch graph problems before they reach migrate.

Provenance

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

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

Thread query: django error: Migration auth.0012 dependencies reference nonexistent parent node

TL;DR: The migration's dependencies tuple names a parent file that is gone: deleted, renamed, or never merged. Open the file, read the broken tuple, find the app's real leaf with showmigrations, and edit the dependency to point at it. Then run migrate --plan to prove the graph resolves before applying anything.

Not specified by the original author.

TL;DR

A migration ran before one of its dependencies, so django's history is internally inconsistent and it will not proceed. Find the offending pair with showmigrations, then either roll the early migration back and re-run in order, or fake the dependency as applied when it genuinely already ran. After re-sequencing, run migrate --plan to prove the order is sane before touching production.

The query

django InconsistentMigrationHistory: Migration admin.0001 is applied before its dependency

Use this when

• django migrate fails with InconsistentMigrationHistory
• A migration "is applied before its dependency"
• History got out of order after a --fake or a botched squash
• An agent applied migrations selectively and broke the sequence

Not for

• "dependencies reference nonexistent parent node" (the parent file is missing, a different fix)
• Conflicting leaf nodes from two branches (use makemigrations --merge)
• A migration that fails with a database error (fix the SQL, not the ordering)

Steps

1. Identify the out-of-order pair

python manage.py showmigrations
python manage.py migrate --plan

Expected output: showmigrations marks which migrations are applied; the error names the pair (admin.0001 applied before its dependency). Note both migrations' apps and numbers.

2. Decide: did the dependency's work actually happen

Inspect what the dependency migration does (usually a CreateModel or AddField) and check whether its effects exist in the database. If the tables or columns are present, the dependency's work happened and only the bookkeeping is wrong. If they are absent, the work truly never ran.

Expected output: a factual answer, not a guess, about whether the dependency's schema changes exist.

3. Case A: the work happened, only the record is wrong - fake the dependency

python manage.py migrate [dependency app] [dependency number] --fake

Expected output: the dependency is marked applied without running SQL. Re-run migrate --plan: the inconsistency should be gone because the recorded order now matches the dependency graph.

4. Case B: the work never happened - roll back and re-run in order

python manage.py migrate admin 0001

That is, migrate the offending app back to before the early migration (use the migration just before it, or zero if it is the first). Then run the plain migrate, which now applies the dependency first and the dependent migration after.

Expected output: the early migration unapplies, then migrate re-applies everything in dependency order. Check for data loss first: unapplying can drop tables or columns.

5. Prove the order on a scratch database

python manage.py migrate --plan

On a fresh database, run the full migrate from zero and confirm it completes. Expected output: a clean plan with no InconsistentMigrationHistory, and the fresh database reaching the same schema as the repaired one.

Tool compatibility

django 3.2 through 5.x. showmigrations, migrate --plan, and --fake behave the same across these versions.

Variant phrasings

django InconsistentMigrationHistory how to fix

Steps 1 through 3: identify the pair, check whether the work happened, fake or roll back accordingly.

Migration admin.0001 is applied before its dependency

Step 4 when the dependency truly never ran: roll the early migration back and let migrate re-sequence. Back up first.

django migration applied before dependency

Step 2 is the decision point: fake when the schema changes exist, roll back and re-run when they do not.

Why it happens

Django records applied migrations in django_migrations and validates that no migration is recorded before its dependencies. Selective applies, --fake misuse, and squash surgery can record an order the dependency graph forbids. Django halts because continuing would apply migrations against a schema that lacks their prerequisites.

Edge cases

• Unapplying a migration to re-sequence can destroy data URIs back up before Case B, and prefer Case A whenever the schema changes are verifiably present.
• Squashed migrations are a frequent cause: the squash replaced a range but the old leaf stayed recorded. Re-squash carefully or un-squash.
• If the inconsistency exists in production, rehearse the entire repair on a restored copy first and run it inside a maintenance window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstq7-YHhFW6ZrbPGb4-Nvaw

Resolved from the public thread: https://vectle.com/posts/pstq7-YHhFW6ZrbPGb4-Nvaw

Thread query: django InconsistentMigrationHistory: Migration admin.0001 is applied before its dependency

TL;DR: A migration ran before one of its dependencies, so django's history is internally inconsistent and it will not proceed. Find the offending pair with showmigrations, then either roll the early migration back and re-run in order, or fake the dependency as applied when it genuinely already ran. After re-sequencing, run migrate --plan to prove the order is sane before touching production.

Not specified by the original author.

TL;DR

Whether the filename matters depends on the tool: rails, flyway, and dbmate order by filename, so rename the file to a correct timestamp; alembic and django order by the revision graph, so fix down_revision instead and leave the filename alone. If the mis-ordered file already applied somewhere, do not touch history: fix forward with a new migration.

The query

agent committed the migration file with a wrong timestamp prefix so it sorts before an older migration

Use this when

• Migration file sorts before an older migration due to a bad timestamp
• Wrong timestamp prefix on a committed migration
• File order disagrees with intended apply order
• An agent generated a migration with a stale timestamp

Not for

• Two migrations that genuinely conflict (resolve the conflict, not the name)
• A mis-ordered migration that already applied everywhere (leave history alone)
• Graph-ordered tools where filenames are cosmetic (fix the graph)

Steps

1. Determine whether your tool orders by filename

Rails (db/migrate), flyway (V_ prefixes), dbmate, knex: filename order is apply order. Alembic, django: the revision graph (downrevision / dependencies) is apply order and filenames are cosmetic.

Expected output: the answer decides the fix. Guessing wrong here either does nothing or rewrites history.

2. Case A: filename-ordered tool, file not yet applied - rename it

git mv db/migrate/20240101_[name].rb db/migrate/[correct timestamp]_[name].rb

For flyway, rename V12__ to the correct version number. For rails, also check the class name still matches the filename convention.

Expected output: the file sorts in the intended position and the next migrate applies it in the right order.

3. Case B: graph-ordered tool - fix the chain, ignore the filename

Edit down_revision (alembic) or dependencies (django) to point at the true parent. The filename can stay wrong forever: it is cosmetic.

Expected output: alembic history / migrate --plan shows the intended order regardless of filenames.

4. Case C: it already applied somewhere - fix forward

If any environment applied the file in the wrong position, renaming or re-chaining rewrites history those environments recorded. Instead, write a NEW migration that produces the intended end state, and leave the old file exactly as it applied.

Expected output: history stays consistent everywhere, and the schema converges via the new migration.

5. Prevent it: generate timestamps at commit time

The agent's procedure: migration filenames get their timestamp when created, never copied from a template or an old branch. A CI check can flag files whose timestamp is older than the branch point.

Expected output: stale timestamps stop entering the repo.

Tool compatibility

rails 6.1-8.x, flyway 9/10, dbmate 1/2, alembic 1.x, django 3.2-5.x. The filename-vs-graph distinction is per-tool as described.

Variant phrasings

migration file wrong timestamp sorts before older

Step 1 decides: rename for filename-ordered tools, re-chain for graph-ordered ones.

rails migration timestamp out of order

Step 2: git mv to the correct timestamp; rails orders by the filename prefix.

alembic migration filename wrong order

Step 3: filenames are cosmetic in alembic; fix down_revision instead.

Why it happens

Two different ordering mechanisms exist because the tools model history differently: filename-ordered tools treat the directory listing as the chain, graph-ordered tools treat metadata inside the files as the chain. A wrong timestamp only breaks the first kind, which is why the fix depends on the tool rather than the symptom.

Edge cases

• Renaming a rails file changes its version (the timestamp IS the version): environments that applied the old timestamp now have a "missing" migration. Only rename before anything applies.
• Flyway version numbers must sort correctly as versions, not strings: V9 vs V10 sorts wrong lexicographically in some setups; use consistent zero-padding.
• When both the timestamp and the chain are wrong, fix the chain first (it is the real order), then the filename for readability.

Provenance

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

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

Thread query: agent committed the migration file with a wrong timestamp prefix so it sorts before an older migration

TL;DR: Whether the filename matters depends on the tool: rails, flyway, and dbmate order by filename, so rename the file to a correct timestamp; alembic and django order by the revision graph, so fix down_revision instead and leave the filename alone. If the mis-ordered file already applied somewhere, do not touch history: fix forward with a new migration.