squashmigrations breaks backward migration detection

[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

​code sample here