`apps` passed to post_migrate_signal should contain migrated appconfigs even when no migration has been applied to them

[tkhyn]

Hi,

I noticed that when one runs migrate without arguments (implicitly migrating all apps), the apps instance passed to emit_post_migrate_signal ​here) contains the migrated apps' configurations only in the first run.

On subsequent runs, the plan list (​here) is empty and post_migrate_apps is set to pre_migrate_apps (​here), i.e. the unmigrated apps.

For example, when calling migrate with the contenttypes app enabled, this means that after the first run update_contenttypes (​here) is passed an apps instance with contenttypes missing. The consequence is that update_contenttypes can not go further than ​this line.

To temporarily fix the issue and correctly trigger the post_migrate_signal so that the content types are properly updated each time migrate is called (and not only the first time), I need to run flush just after migrate. I don't think it should not be needed to run flush simply to correctly trigger the post_migrate_signal that will update the content types.

It worked fine in Django 1.9.9 as no project state apps instance is passed to emit_post_migrate_signal, and update_contenttypes uses the global apps instance.

I don't really know enough about the recent developments regarding apps management in Django, so I'm not sure what should be done to solve this issue. Thanks in advance if somebody has the time to look at it.

Context: I'm testing a reusable django app (​django-gm2m) which test suite includes migration tests for a number of mini test apps with different models (see ​here). Whenever I switch to another mini-app, the database needs not only to be flushed but also re-migrated and the contenttypes need to be updated ''

[Tim Graham]

I'm not sure I understand entirely. I think the idea is that if no migrations are applied, then content types shouldn't need to be updated. How can we reproduce the issue to look into it? Run the test suite for your app?