Opened 68 minutes ago
#37077 assigned Uncategorized
TransactionTestCase.serialized_rollback doesn't run tests when database includes a mirror in parallel
| Reported by: | Jake Howard | Owned by: | Jake Howard |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 5.2 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
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):
- In
django.test.utils.setup_databases.serialize_connectionsis never added to for mirrored aliases, meaning the contents is never serialized. - In
DiscoveryRunner.run_tests.suite.serialized_aliasesis 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).