[Django] #31254: "populate() isn't reentrant" masks underlying error
Django
-----------------------------------------+------------------------
Reporter: TK-23 | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31254>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: TK-23 | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by TK-23):
* type: Uncategorized => Bug
--
Ticket URL: <https://code.djangoproject.com/ticket/31254#comment:1>
Django
Reporter: TK-23 | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
> 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31254#comment:2>
Django
Reporter: TK-23 | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* cc: Carlton Gibson (added)
* status: new => closed
* resolution: => needsinfo
Comment:
I'm going to close this as needsinfo for the moment. If you can add a
reproduce I'm happy to look at it!
--
Ticket URL: <https://code.djangoproject.com/ticket/31254#comment:3>
Django
Reporter: TK-23 | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Timothy Schilling):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31254#comment:4>
Django
Reporter: TK-23 | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Timothy Schilling):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/31254#comment:5>
Django
Reporter: TK-23 | Owner: nobody
Type: Bug | Status: closed
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
@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)? 👍
--
Ticket URL: <https://code.djangoproject.com/ticket/31254#comment:6>