Skip to content

Fixed #36083 -- Ran system checks in ParallelTestSuite workers #19070

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

adamzap
Copy link
Member

@adamzap adamzap commented Jan 18, 2025

Trac ticket number

ticket-36083

Branch description

Workers created by ParallelTestSuite were not running system checks. In general this is fine, but system checks can have side effects that the tests expect.

This patch runs system checks inside of _init_worker, which is only called by ParallelTestSuite.

Checklist

  • This PR targets the main branch.
  • The commit message is written in past tense, mentions the ticket number, and ends with a period.
  • I have checked the "Has patch" ticket flag in the Trac system.
  • I have added or updated relevant tests.
  • I have added or updated relevant docs, including release notes if applicable.
  • I have attached screenshots in both light and dark modes for any UI changes.

@adamzap
Copy link
Member Author

adamzap commented Jan 18, 2025

@jacobtylerwalls The tests probably aren't done yet, but is this the direction you had in mind when we talked on Discord about unit testing _init_worker as part of this ticket? There's a ton of mocking here, but I figured it wasn't safe to set up an actual Django environment with a database just for these tests. Let me know how you think I should proceed, and thanks for the help!

Copy link
Member

@jacobtylerwalls jacobtylerwalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks right-track to me. This feels like the root of the problem with the parallel test runner, since system checks can have side effects (and will have them for the foreseeable future).

The symptom with available_apps making it impossible to boot the WSGI server given default middleware seems like just one possible symptom. Adding exceptions around that might just make things harder to reason about later?

Nice coverage increase, too.

I'm sure others will have thoughts. Left a couple minor comments. Thanks for picking this up!

@jacobtylerwalls
Copy link
Member

It might be nice to look into whether we can de-dupe the results from the system checks. Running with 7 processes and getting 7x the diagnostics is not ideal.

@adamzap
Copy link
Member Author

adamzap commented Jan 24, 2025

@jacobtylerwalls Do you think anything else is needed to move this PR out of draft status?

@jacobtylerwalls
Copy link
Member

Looks ready for review to me. Just reiterating (and I think you already know this) that there will probably be more discussion on whether this is the right path to take, but having a PR ready for review will help with decision making, I'm sure, so thank you!


Re: what path to take here, my thinking is that if Django itself has system checks with side effects, it's reasonable to assume users will too. The parallel test runner is supposed to do whatever the regular runner does, just faster. So running the system checks on fork seems like a way to remove a vector for bugs. The alternatives we looked at on the ticket had drawbacks, but maybe someone will still think of something clever 👍

@adamzap adamzap marked this pull request as ready for review January 25, 2025 18:51
@adamzap adamzap changed the title Fixed #36083 -- Fixed LiveServerTestCase with parallel test runner Fixed #36083 -- Ran system checks in ParallelTestSuite workers Jan 25, 2025
@mock.patch("django.test.runner.setup_test_environment")
@mock.patch("django.setup")
@mock.patch("multiprocessing.get_start_method")
class InitWorkerTests(SimpleTestCase):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The _init_worker function was not unit tested.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate that these add tests so that something would fail if we revert but I don't love that these tests just check that _init_worker is as defined. Would be good to have something slightly more meaningful if we can

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair. I have a feeling that _init_worker wasn't tested before because it's difficult to test. I'll try to look into a better approach, but I'm open to suggestions in the meantime.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jacobtylerwalls Would you have any thoughts or guidance on quality of the test?

Workers created by ParallelTestSuite were not running system checks.
In general this is fine, but system checks can have side effects that
the tests expect.

This patch runs system checks inside of _init_worker, which is only
called by ParallelTestSuite.
Copy link
Contributor

@sarahboyce sarahboyce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm ok with the approach. Will ask if @adamchainz has an opinion here?

@jacobtylerwalls I couldn't replicate the issue, can you confirm the issue is still there and this fixes it?

@mock.patch("django.test.runner.setup_test_environment")
@mock.patch("django.setup")
@mock.patch("multiprocessing.get_start_method")
class InitWorkerTests(SimpleTestCase):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate that these add tests so that something would fail if we revert but I don't love that these tests just check that _init_worker is as defined. Would be good to have something slightly more meaningful if we can

@jacobtylerwalls
Copy link
Member

jacobtylerwalls commented Aug 6, 2025

Yep, the issue is still reproducible on Mac and this PR fixes it. (I would hazard you could reproduce yourself if you multiprocessing.set_start_method("spawn"), or else switch to Windows, or if on unix, switch to Python 3.14 (maybe🤞 ))

However, I'm hoping we can do something about the additional "System check identified no issues" if not too complicated:

Example output
(py313) jwalls@Jacobs-MacBook-Pro tests % ./runtests.py file_storage.tests
Testing against Django installed in '/Users/jwalls/django/django' with up to 10 processes
Found 146 test(s).
Creating test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
Cloning test database for alias 'default'...
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
.......System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
System check identified no issues (0 silenced).
........................................................System check identified no issues (0 silenced).
...................................................................................
----------------------------------------------------------------------
Ran 146 tests in 1.523s

OK
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...
Destroying test database for alias 'default'...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants