#37077: TransactionTestCase.serialized_rollback doesn't run tests when database
includes a mirror in parallel
-----------------------------------+---------------------------------------
Reporter: Jake Howard | Owner: Jake Howard
Type: Bug | Status: assigned
Component: Testing framework | Version: 5.2
Severity: Normal | Resolution:
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 Jacob Walls):
* component: Database layer (models, ORM) => Testing framework
* type: Uncategorized => Bug
Old description:
> In a very specific situation, the test runner skips running tests, and
> just terminates (successfully). Instead of running the tests, the
> database is set up, cloned for each process, then destroyed without
> running any tests. This is related to the changes from #35967
>
> With a `TransactionTestCase` with `serialized_rollback=True`, and a
> project with multiple `DATABASES` where one is a mirror of the other,
> where both connections are needed for the test (eg `databases =
> "__all__"). If a `TransactionTestCase` isn't going to be run, this
> behaviour isn't seen.
>
> The cause is that in `ParallelTestSuite.initialize_suite`, an
> `AttributeError` is raised when accessing
> `connections[alias]._test_serialized_contents`, because contents is never
> set.
>
> This could be resolved in 2 ways (at least that I've found):
>
> 1. In `django.test.utils.setup_databases`. `serialize_connections` is
> never added to for mirrored aliases, meaning the contents is never
> serialized.
> 2. In `DiscoveryRunner.run_tests`. `suite.serialized_aliases` is set to
> all databases, and doesn't exclude mirrors (where serialization isn't
> necessary).
>
> I've written (crude) fixes for both, and both resolve the issue, but I'm
> not sure which makes the most sense (maybe both?). I suspect the correct
> answer is option 2, since serializing (and restoring) mirrors makes
> little sense, but interested in some more opinions.
>
> I've tested this issue is also present on 5.2 (requires `spawn`
> multiprocessing mode).
New description:
In a very specific situation, the test runner skips running tests, and
just terminates (successfully). Instead of running the tests, the database
is set up, cloned for each process, then destroyed without running any
tests. This is related to the changes from #35967
With a `TransactionTestCase` with `serialized_rollback=True`, and a
project with multiple `DATABASES` where one is a mirror of the other,
where both connections are needed for the test (eg `databases =
"__all__"`). If a `TransactionTestCase` isn't going to be run, this
behaviour isn't seen.
The cause is that in `ParallelTestSuite.initialize_suite`, an
`AttributeError` is raised when accessing
`connections[alias]._test_serialized_contents`, because contents is never
set.
This could be resolved in 2 ways (at least that I've found):
1. In `django.test.utils.setup_databases`. `serialize_connections` is
never added to for mirrored aliases, meaning the contents is never
serialized.
2. In `DiscoveryRunner.run_tests`. `suite.serialized_aliases` is set to
all databases, and doesn't exclude mirrors (where serialization isn't
necessary).
I've written (crude) fixes for both, and both resolve the issue, but I'm
not sure which makes the most sense (maybe both?). I suspect the correct
answer is option 2, since serializing (and restoring) mirrors makes little
sense, but interested in some more opinions.
I've tested this issue is also present on 5.2 (requires `spawn`
multiprocessing mode).
--
Comment:
Oh, this is going to be fun. I'm surprised that `AttributeError` doesn't
cause a non-zero exit. If I throw an `AttributeError` inside
`initialize_suite`, I get a nice failure. What's going on there?
Can you share the `DATABASES` you reproduced with, so we can see how your
`["TEST"]["MIRROR"]` is configured?
--
Ticket URL: <https://code.djangoproject.com/ticket/37077#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019ddb08568a-6c101a11-f407-4e9a-b7ec-b8f183adb4d8-000000%40eu-central-1.amazonses.com.
