Defining a custom user model in an app and having relations between it and other models in the app causes circular dependencies

[Stephen Burrows]

I *think* the issue is that swappable_dependency resolves to app_label.first, which doesn't make a lot of sense when the app with the migrations is itself being migrated. Removing that line seems to temporarily resolve the issue, but if my app were ever used with a *different* AUTH_USER_MODEL, it would then presumably break again. (Also, I still get a circular dependency in the next migration that defines a relation to AUTH_USER_MODEL.)

Here are the important bits from *one* migration:

class Migration(migrations.Migration):

    dependencies = [
        migrations.swappable_dependency(settings.AUTH_USER_MODEL),
        ('app_label', '0002_blah_blah'),
    ]

    operations = [
        migrations.CreateModel(
            # This is the AUTH_USER_MODEL
            name='Person',
            fields=[
                ...
            ],
            options={
                u'verbose_name': u'person',
                u'verbose_name_plural': u'people',
            },
            bases=(models.Model,),
        ),
        migrations.CreateModel(
            name='PersonDiscount',
            fields=[
                ...
                ('person', models.ForeignKey(to=settings.AUTH_USER_MODEL, to_field=u'id')),
            ],
            options={
            },
            bases=(models.Model,),
        ),
    ]

Traceback:

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File ".../django/django/core/management/__init__.py", line 427, in execute_from_command_line
    utility.execute()
  File ".../django/django/core/management/__init__.py", line 419, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File ".../django/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File ".../django/django/core/management/base.py", line 337, in execute
    output = self.handle(*args, **options)
  File ".../django/django/core/management/commands/migrate.py", line 103, in handle
    plan = executor.migration_plan(targets)
  File ".../django/django/db/migrations/executor.py", line 46, in migration_plan
    for migration in self.loader.graph.forwards_plan(target):
  File ".../django/django/db/migrations/graph.py", line 53, in forwards_plan
    return self.dfs(node, lambda x: self.dependencies.get(x, set()))
  File ".../django/django/db/migrations/graph.py", line 119, in dfs
    return _dfs(start, get_children, [])
  File ".../django/django/db/migrations/graph.py", line 111, in _dfs
    results = _dfs(n, get_children, path) + results
  File ".../django/django/db/migrations/graph.py", line 111, in _dfs
    results = _dfs(n, get_children, path) + results
  File ".../django/django/db/migrations/graph.py", line 111, in _dfs
    results = _dfs(n, get_children, path) + results
  File ".../django/django/db/migrations/graph.py", line 103, in _dfs
    raise CircularDependencyError(path[path.index(start):] + [start])
django.db.migrations.graph.CircularDependencyError: [('brambling', '0003_blah_blah'), ('brambling', '0003_blah_blah')]

[nliberg]

Fix circular dependency by building dependency graph in 2 stages

[nliberg]

As far as I can see the error is in the build_graph method of the MigrationLoader class.
The self.graph.root_nodes(...) method seems to be invoked before the graph is fully built resulting in some extra nodes in the returned set that are root nodes in the current partial graph but are not root nodes in the final graph. Since the parent of the dependency relationship is drawn from this set of nodes one can end up with an incorrect loop from the node to itself in the graph. This results in a CircularDependencyError exception at a later stage.

The problem seem to be fixed by building the graph in two steps: first handling all normal nodes and then the "__first__" nodes (that get remapped to a root node). Someone with a deeper understanding of the relevant code will have to be the judge of whether this is a partial or complete fix. At least the patch above fixes the problem for me.

[Jonas von Poser]

I can confirm this bug and that the patch resolves it. Will be happy to assist with further tests.

[Baptiste Mispelon]

Triaging this per the previous comment

[Jonas von Poser]

I submitted a pull request with a test here: ​https://github.com/django/django/pull/2581

As mentioned in the pull request, the patch does not work for the test I added - while it does work for my actual code. This is the first test I wrote for Django itself so it might be due to some error on my part. Trying it for a while, I couldn't find it though. Would appreciate some help in getting this mergeable.

[Andrew Godwin <andrew@…>]

In 5400b29ebfdcd8fb657bf42ddd6f81764b99f63a:

Fixed #22325: Ignore first dependencies to your own app

[Andrew Godwin <andrew@…>]

In 1e8b1db050de72edc3c434e6e5d5dd55ae78ae2e:

[1.7.x] Fixed #22325: Ignore first dependencies to your own app

[Andrew Godwin]

Jonas: I'm reasonably sure the patch I just pushed is the real fix, based on what I know of the problem, but would appreciate if you could make sure it works for your code.

(I forgot to add the test to that commit, it's in one just afterward. Thanks for helping with that)

[Bas Peschier]

I can't speak for Jonas, but I had similar symptoms which as of this commit are nonexistent. Thanks!

[Jonas von Poser]

Yep, works for me as well. Thanks!