Re: [Django] #36083: LiveServerTestCase fails in parallel test runner if django.contrib.auth.backends has not yet been imported

Django

unread,

Jan 12, 2025, 12:47:11 AM1/12/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Adam Zapletal):

Great job researching this, and thanks for the quick response!

For context, I found this issue while working on #10244, and this is not
my area of expertise in the codebase. However, here are my initial
thoughts on the options you presented:

1. Yes, the diff is a bit unfortunate, but running system checks in each
worker seems more correct to me if I'm understanding the design correctly.
It seems like we'd want to run them in every context or none.
2. This seems like a simple band-aid fix that would work for now if this
ticket has a deadline. I'm not sure of all the implications here.
3. I agree that this seems correct in a way similar to the first option.
We don't want to evade system checks on accident.

----

I'm a bit thrown off by the fact that
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/django/contrib/auth/checks.py#L240-L262
the system check in question], via `‎_subclass_index`, has the side effect
of importing a module. I'm wondering the following:

1. Are there other system checks with side effects?
2. Is there a way to implement this system check without the side effect?

I'm not familiar enough with the system check framework to know what's
reasonable here, though I'd be interested to know.

----

This may be irrelevant, but if I grep the test suite for uses of
`LiveServerTestCase`, I find the following:

1. Tests testing aspects `LiveServerTestCase` itself (and
`StaticLiveServerTestCase`)
2.
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/admin_scripts/tests.py#L2522-L2528
A test class] for the `startproject` command that sets `available_apps`
correctly
3.
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/file_storage/tests.py#L1241
The file storage test class] that this ticket is about, which sets
`available_apps` to an empty list (for context, `available_apps` was set
[https://github.com/django/django/commit/c6e6d4eeb776c473567362405cdbc6a0328eb194
#diff-909f29df9f82791ff799d183cbcd685c30732b09822fc002a3b8df5df50d4883R625
here].)

So we can say that the test class in question is the only one in the whole
test suite that uses `LiveServerTestCase` but doesn't include
`django.contrib.auth` in `available_apps`. I'm not sure what that implies,
but this test is an outlier in multiple ways. Should the test itself be
questioned?
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

Jan 12, 2025, 10:23:33 AM1/12/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

Thanks Adam.

> Is there a way to implement this system check without the side effect?

To find out whether a middleware class declared by a string is a subclass
of something else, I think we have to import the string.

I may have skewed things by using the phrase "side effect": I think it's
good to admit flexibility in the order by which modules are imported. As
the long as the module-level caches are designed well, then in practice
it's not really a problem. It does raise test isolation concerns.

The test framework goes to great effort to reset the database layer
between tests, but the python layer is left up to the user. It might be
worthy to try out adding an `--isolate-imports` flag to the test runner in
a third-party package that would reset `sys.modules` between test case
classes. (I don't know if there's a test framework out there that already
implements such a thing.)

Here is where I would cc Adam Johnson if I had the right permission bit.

> Should the test itself be questioned?

Thanks for the grep -- it's true Django itself only has one test case
class in this situation, but a user could be doing this. I think there
would have been a similar problem with `SeleniumTestCase` if it were
supported by the parallel test runner. (It doesn't today but might in the
future.)

> This seems like a simple band-aid fix that would work for now if this
ticket has a deadline.

I tenatively marked this as a release blocker since it smelled like a
regression in Django 5.2: your test case class breaks if it depends on
`django.contrib.auth` via `LiveServerTestCase` (or `SeleniumTestCase` if
they have a way to run it in parallel or skip checks) but sets
`available_apps = []`. The wrinkle being that `available_apps` is a
private API we can change at will. I'll let the fellows speak to urgency.

> Option 3 feels more semantically correct but would need some thought
around the design to make it ergonomic (fiddling with this in every
subclass doesn't seem right)

We could also just doc that `LiveServerTestCase` subclasses should be
careful to to include auth in available_apps, given we've already
documented this as an advanced/private feature. Or add fanciness to to
`LiveServerTestCase._pre_setup()` to sniff for this misconfiguration, but
the complexity tradeoff looks bad if we need to be resilient against
subclasses of the auth middleware (hence the whole reason for
`_subclass_index` in the system check in the first place).

> 2. This seems like a simple band-aid fix that would work for now if this
ticket has a deadline. I'm not sure of all the implications here.

Re: shuffling the cheese around in `LiveServerTestCase.setUpClass()`, I
guess it has the benefit of clarifying that `available_apps` is really
only about signals and the database layer, and we could say that it's not
a way to adjust the app registry for other purposes like skipping imports.

----
I'm fine with any of the three options. Would like to hear from others.
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:5>

Django

unread,

Jan 12, 2025, 10:28:09 PM1/12/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Adam Zapletal):

I appreciate your insight here. Please know that I wasn't questioning your
approach...I'm just trying to understand the problem!

----

One point of clarification on this comment:

> Thanks for the grep -- it's true Django itself only has one test case
class in this situation, but a user could be doing this. I think there
would have been a similar problem with SeleniumTestCase if it were
supported by the parallel test runner. (It doesn't today but might in the
future.)

I was assuming that in a real project (not Django itself), the user
wouldn't have this problem. They'd be opting into setting `available_apps`
on their test class, so we can expect them to do it correctly. The
attribute is only required
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/runtests.py#L314
in Django's test suite].

When I remove the linked check from `runtests.py` or set `available_apps`
to `None`, the test in question passes.

----

I'd like to hear from others as well. Do you want to ping people on this
ticket, or should we open a forum thread?
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:6>

Django

unread,

Jan 12, 2025, 10:28:40 PM1/12/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Description changed by Adam Zapletal:

Old description:

> The full test suite run with multiple threads passes for me, but when I
> run the `tests.file_storage.tests` file in isolation (`./runtests.py
> file_storage.tests`), I get a failure. It passes in isolation if I run
> the tests with only one thread (`./runtests.py --parallel 1
> file_storage.tests`). This happened to others when I asked about it in
> the Django Discord server, but not everyone. For what it's worth, I'm on
> the latest macOS running Python v3.12.
>
> When a failure happens, I get the following error:
>
> `django.core.exceptions.ImproperlyConfigured: AUTH_USER_MODEL refers to
> model 'auth.User' that has not been installed`
>
> I have narrowed the issue down to the fact that this test file contains a
> class that inherits from `LiveServerTestCase`. It seems like any test
> file that mixes `LiveServerTestCase` and something more normal like
> `unittest.TestCase` will fail for me when run in isolation with more than
> one thread.
>
> Here's a minimal example if anyone is interested:
>
> {{{#!python
> from unittest import TestCase
>
> from django.test import LiveServerTestCase
>

> class TestCaseTests(TestCase):
> def test(self):
> self.assertEqual(2, 2)
>

> class LiveServerTestCaseTests(LiveServerTestCase):
> available_apps = []
>
> def test(self):
> self.client.get(self.live_server_url + '/')
> }}}
>
> I have a fix, but I'm not sure if it's a good one. Setting
> `available_apps = ['django.contrib.auth']` on the
> `LiveServerTestCase`-based class fixes it as one would expect from the
> error message, but I wonder if this is hiding something like a race
> condition. I wonder why it passes the full test suite when run with
> multiple threads, but it can't pass in isolation when run with multiple
> threads.
>
> Should I open a pull request to fix
> [https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/file_storage/tests.py#L1241
> the test] in the way I mentioned above, or is something deeper going on
> here? It could be that I'm misunderstanding something about how
> `LiveServerTestCase` is isolated during test runs.

New description:

The full test suite run with multiple threads passes for me, but when I
run the `tests.file_storage.tests` file in isolation (`./runtests.py
file_storage.tests`), I get a failure. It passes in isolation if I run the
tests with only one thread (`./runtests.py --parallel 1
file_storage.tests`). This happened to others when I asked about it in the
Django Discord server, but not everyone. For what it's worth, I'm on the
latest macOS running Python v3.12.

When a failure happens, I get the following error:

`django.core.exceptions.ImproperlyConfigured: AUTH_USER_MODEL refers to
model 'auth.User' that has not been installed`

I have narrowed the issue down to the fact that this test file contains a
class that inherits from `LiveServerTestCase`. It seems like any test file
that mixes `LiveServerTestCase` and something more normal like
`unittest.TestCase` will fail for me when run in isolation with more than
one thread.

Here's a minimal example if anyone is interested:

{{{#!python
from unittest import TestCase

from django.test import LiveServerTestCase

class TestCaseTests(TestCase):
def test(self):
self.assertEqual(2, 2)

class LiveServerTestCaseTests(LiveServerTestCase):
available_apps = []

def test(self):
self.assertEqual(2, 2)
}}}

I have a fix, but I'm not sure if it's a good one. Setting `available_apps
= ['django.contrib.auth']` on the `LiveServerTestCase`-based class fixes
it as one would expect from the error message, but I wonder if this is
hiding something like a race condition. I wonder why it passes the full
test suite when run with multiple threads, but it can't pass in isolation
when run with multiple threads.

Should I open a pull request to fix
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/file_storage/tests.py#L1241
the test] in the way I mentioned above, or is something deeper going on
here? It could be that I'm misunderstanding something about how
`LiveServerTestCase` is isolated during test runs.

--
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:7>

Django

unread,

Jan 12, 2025, 11:41:34 PM1/12/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

No worries Adam, I didn't think you were questioning me at all. I
appreciate you thinking it through with me! We'll hear from others soon,
as it's still the weekend in my timezone.

> They'd be opting into setting available_apps on their test class, so we
can expect them to do it correctly.

I agree with that. I guess I'm taking the opportunity to wonder about what
is correct: if `LiveServerTestCase` is what creates the dependency on
`contrib.auth` purely by instantiating `WSGIHandler()`, should we expect
that to leak to the subclasses, meaning they have to either not use the
`available_apps` attribute ''or'' discover for themselves this tricky edge
case and guard against it for the first time in 5.2? Again, not
necessarily a regression/release blocker given that it's a private API,
just polling for views since we at least have the ''option'' of preventing
an unintentional behavior change here.
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:8>

Django

unread,

Jan 13, 2025, 7:10:25 AM1/13/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* cc: Adam Johnson (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:9>

Django

unread,

Jan 15, 2025, 8:05:37 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Sarah Boyce):

I think in the interest of time, we should do option 2. We can create a
followup cleanup/optimization ticket for option 3
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:10>

Django

unread,

Jan 15, 2025, 8:29:54 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------

Reporter: Adam Zapletal | Owner: Jacob
| Walls
Type: Bug | Status: assigned

Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Jacob Walls):

* owner: (none) => Jacob Walls
* status: new => assigned

Comment:

Sounds great, I can put together a PR for this this morning.
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:11>

Django

unread,

Jan 15, 2025, 8:30:21 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Jacob
| Walls
Type: Bug | Status: assigned
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

No worries if someone else beats me to it
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:12>

Django

unread,

Jan 15, 2025, 9:00:08 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Jacob
| Walls
Type: Bug | Status: assigned
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Sarah Boyce):

One thought I had was whether we want to call checks when the installed
apps settings change, something like:
{{{#!diff
--- a/django/test/signals.py
+++ b/django/test/signals.py
@@ -6,6 +6,7 @@ from asgiref.local import Local

from django.apps import apps
from django.core.exceptions import ImproperlyConfigured
+from django.core.management import call_command
from django.core.signals import setting_changed
from django.db import connections, router
from django.db.utils import ConnectionRouter
@@ -52,6 +53,7 @@ def update_installed_apps(*, setting, **kwargs):
from django.utils.translation import trans_real

trans_real._translations = {}
+ call_command("check")

}}}
For the specific test failure, we should probably set the middleware to be
[]
This would have some performance impact though 🤔
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:13>

Django

unread,

Jan 15, 2025, 9:00:32 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Jacob
| Walls
Type: Bug | Status: assigned
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Sarah Boyce):

> I can put together a PR for this this morning.

Thank you so much
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:14>

Django

unread,

Jan 15, 2025, 9:48:53 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Jacob
| Walls
Type: Bug | Status: assigned
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

Unfortunately there is a new test failure with option 2, so it's probably
less safe than doing nothing:

{{{
======================================================================
ERROR: test_media_files (servers.tests.LiveServerViews.test_media_files)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/user/django/tests/servers/tests.py", line 310, in
test_media_files
with self.urlopen("/media/example_media_file.txt") as f:
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/user/django/tests/servers/tests.py", line 44, in urlopen
return urlopen(self.live_server_url + url)
File
"/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py",
line 189, in urlopen
return opener.open(url, data, timeout)
~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
File
"/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py",
line 495, in open
response = meth(req, response)
File
"/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py",
line 604, in http_response
response = self.parent.error(
'http', request, response, code, msg, hdrs)
File
"/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py",
line 533, in error
return self._call_chain(*args)
~~~~~~~~~~~~~~~~^^^^^^^
File
"/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py",
line 466, in _call_chain
result = func(*args)
File
"/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py",
line 613, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------
Ran 30 tests in 5.779s
}}}

----
For reference here is the test I was intending to add:
{{{
class LiveServerAvailableAppsTests(LiveServerTestCase):
available_apps = []

@classmethod
def setUpClass(cls):
# Simulate the system checks having not run their side effect of
# importing these modules via check_middleware().
auth_backends = sys.modules.pop("django.contrib.auth.backends",
None)
cls.addClassCleanup(sys.modules.__setitem__,
"django.contrib.auth.backends", auth_backends)
auth_middleware =
sys.modules.pop("django.contrib.auth.middleware", None)
cls.addClassCleanup(sys.modules.__setitem__,
"django.contrib.auth.middleware", auth_middleware)

super().setUpClass()

def test_server_starts_when_system_checks_have_not_run(self):
# Mostly to exercise setUpClass() but also to verify test setup.
self.assertEqual(self.available_apps, [])
}}}

----
Option 3 (Adam's original patch) may be the most practical thing at this
point (and doesn't need to be a blocker, since it's just changing our
existing test.)

Thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:15>

Django

unread,

Jan 15, 2025, 9:58:24 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Jacob
| Walls
Type: Bug | Status: assigned
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Adam Zapletal):

Let me know how I can help. I'm happy to open a PR with the fix from my
original post if that's the direction we want to go in.
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:16>

Django

unread,

Jan 15, 2025, 10:07:19 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------

Reporter: Adam Zapletal | Owner: Adam
| Zapletal

Type: Bug | Status: assigned
Component: Testing framework | Version: dev

Severity: Normal | Resolution:

Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Jacob Walls):

* owner: Jacob Walls => Adam Zapletal
* severity: Release blocker => Normal

Comment:

Thanks, Adam. I can pass the baton to you.

Now that we know option 2 isn't very safe I don't think this is urgent
anymore. Sarah, let me know if you disagree.

I'm starting to like Option 1 again (run system checks per process).
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:17>

Django

unread,

Jan 15, 2025, 10:41:19 AM1/15/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Adam
| Zapletal
Type: Bug | Status: assigned
Component: Testing framework | Version: dev
Severity: Normal | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

unread,

Sep 16, 2025, 9:57:33 PM9/16/25

to django-...@googlegroups.com

#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: Adam
| Zapletal

Type: Bug | Status: closed

Component: Testing framework | Version: dev

Severity: Normal | Resolution: fixed

Keywords: TransactionTestCase | Triage Stage: Ready for
setupclass available_apps | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Jacob Walls <jacobtylerwalls@…>):

* resolution: => fixed
* status: assigned => closed

Comment:

In [changeset:"606fc352799e372928fa2c978ab99f0fb6d6017c" 606fc352]:
{{{#!CommitTicketReference repository=""
revision="606fc352799e372928fa2c978ab99f0fb6d6017c"
Fixed #36083 -- Ran system checks in ParallelTestSuite workers.

Workers created by ParallelTestSuite were not running system
checks in the spawn multiprocessing mode. In general this is
fine, but system checks can have side effects expected by tests.

This patch runs system checks inside of _init_worker, which is
only called by ParallelTestSuite.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:24>

Reply all

Reply to author

Forward