id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
36166	Backwards migration to replaced migration leads to InconsistentMigrationHistory on forward migrate	Klaas van Schelven		"When squashing migrations, migrating back is broken when referencing a now-replaced migration. 

I have migrations as such:

* 0001_initial.py
* 0002_foomodel_bar.py
* 0001_squashed_0002_foomodel_bar.py  squashing 0001 & 0002
* 0003_foomodel_after_squash.py depending on the squashed migration (Django does this by default when making a new migration after squashing, and it's the right thing)

However, after migrating fully, migrating back to the last replaced migration does not actually undo 0003.
 
{{{
$ python manage.py migrate squashme
Operations to perform:
  Apply all migrations: squashme
Running migrations:
  Applying squashme.0001_squashed_0002_foomodel_bar... OK
  Applying squashme.0003_foomodel_after_squash... OK

$ python manage.py migrate squashme 0002
Operations to perform:
  Target specific migration: 0002_foomodel_bar, from squashme
Running migrations:
  No migrations to apply.
(freshdjango) klaas@pop-os:~/dev/squashtest$ python manage.py migrate squashme
Operations to perform:
  Apply all migrations: squashme
Running migrations:
  No migrations to apply.
}}}

Migrating even further back into that chain leads to inconsistent migration history:

{{{
(freshdjango) python manage.py migrate squashme
Operations to perform:
  Apply all migrations: squashme
Running migrations:
  Applying squashme.0001_squashed_0002_foomodel_bar... OK
  Applying squashme.0003_foomodel_after_squash... OK

(freshdjango) klaas@pop-os:~/dev/squashtest$ python manage.py migrate squashme 0001_initial
Operations to perform:
  Target specific migration: 0001_initial, from squashme
Running migrations:
  Rendering model states... DONE
                                                                <= shouldn't there be undoing of 0003?
  Unapplying squashme.0002_foomodel_bar... OK

(freshdjango) klaas@pop-os:~/dev/squashtest$ python manage.py migrate squashme
Traceback (most recent call last):
[..]
    raise InconsistentMigrationHistory(
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration squashme.0003_foomodel_after_squash is applied before its dependency squashme.0002_foomodel_bar on database 'default'.
}}}


Migrating back to the squashing migration instead (if you didn't do the above) does what you'd expect:

{{{
(freshdjango)  python manage.py migrate squashme 0001_squashed_0002_foomodel_bar
Operations to perform:
  Target specific migration: 0001_squashed_0002_foomodel_bar, from squashme
Running migrations:
  Rendering model states... DONE
  Unapplying squashme.0003_foomodel_after_squash... OK
}}}


[https://github.com/vanschelven/squashtest/tree/main/squashme/migrations code sample here]"	Bug	new	Migrations	5.1	Normal			Jacob Walls	Accepted	1	0	0	0	0	0