Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#31254 closed Bug (needsinfo)

"populate() isn't reentrant" masks underlying error

Reported by: TK-23 Owned by: nobody
Component: Core (Other) Version: 2.2
Severity: Normal Keywords:
Cc: Carlton Gibson Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I'm new to reporting bugs, but have struggled with this one enough that I thought I would formally document an issue we've seen.

In django/django/apps/registry.py (https://github.com/django/django/blob/20ba3ce4ac8e8438070568ffba76f7d8d4986a53/django/apps/registry.py#L83) there is a line of code that can raise an error when running simple commands like python manage.py runserver:

if self.loading:
                # Prevent reentrant calls to avoid running AppConfig.ready()
                # methods twice.
                raise RuntimeError("populate() isn't reentrant")

The problem is that this generic error can mask the true reason why django will not start up (I've seen the true reason be something like a problem with a version of a Python package needing to be updated, or an import of a module that does not exist elsewhere in the code). Based on a stackoverflow response (https://stackoverflow.com/questions/27093746/django-stops-working-with-runtimeerror-populate-isnt-reentrant) I've learned to comment out raise RuntimeError("populate() isn't reentrant") and replace it with self.app_configs={}

This way the true error will be exposed when starting up django. I do not know the best way to handle this but before I found this stackoverflow post, we lost a lot of time trying to debug issues. Even knowing this workaround it is a hassle to adjust the django code to see the true error.

I can provide a link to our opensource project with a branch set up to replicate the error if that is helpful.

Change History (6)

comment:1 by TK-23, 5 years ago

Type: UncategorizedBug

comment:2 by Carlton Gibson, 5 years ago

I can provide a link to our opensource project with a branch set up to replicate the error if that is helpful.

Yes please. I would expect that the "true error" would be exposed earlier in the logs, so it would be good to see the reproduce.
Thanks.

comment:3 by Carlton Gibson, 5 years ago

Cc: Carlton Gibson added
Resolution: needsinfo
Status: newclosed

I'm going to close this as needsinfo for the moment. If you can add a reproduce I'm happy to look at it!

comment:4 by Timothy Schilling, 3 years ago

I was able to reproduce this by creating a second app named auth. This was fixed in https://code.djangoproject.com/ticket/21679, but there's no check or indication that was the problem.

I believe django.setup eats the ImproperlyConfigured exception that's raised.

comment:5 by Timothy Schilling, 3 years ago

Moving the self.loading comparison and set after the two known cases of raising ImproperlyConfigured seems to resolve the issue. If I could get some direction regarding how to write that test, I'll get this implemented. That said, I'm not sure this exception case is covered in the tests: https://github.com/django/django/commit/7ed20e015335076fc98ad805eaf241f8a0d872d5

comment:6 by Carlton Gibson, 3 years ago

@Tim — thanks for pursuing this. Can you put what you have in a PR maybe so it's easier to review (and have a play with)? 👍

Note: See TracTickets for help on using tickets.
Back to Top