-
Notifications
You must be signed in to change notification settings - Fork 344
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
Incompatible scopes of live_server and transactional_db #454
Comments
Running into this as well. Did you find anything? |
Nope. I'll report my findings here if I find time to work on a solution. It isn't near the top of my TODO list. |
I'm having the same(?) problem, live_server fixture does not see changes made to the database, running in it's own transaction. @aaugustin , does it sound likely to you? I was wondering... maybe I should ditch the live_server fixture totally and just write my replacement. It would consist of running "manage.py runserver" in a thread. Except pointing it to a test database, I'd not update project settings. At some point I may need that. Also, LiveServerTestCase does not support custom STATICFILES_FINDERS except the filesystem one... |
I'm also running into this issue. Current workaround I'm using is to override the from pytest_django.fixtures import live_server as orig_live_server
@pytest.fixture(scope='function')
def live_server(request):
"""
Workaround inspired by https://github.com/mozilla/addons-server/pull/4875/files#diff-0223c02758be2ac7967ea22c6fa4b361R96
"""
return orig_live_server(request) This seems like it's working, though admittedly, it slows all the test cases that use it way down. If anyone sees a problem with this approach, please let me know. |
I have similar problem: The @Helumpago's workaround fixed this error for me. But pytest prints this warning:
Is there any other way to use |
The @Helumpago's workaround raises an error instead of warning since pytest 4.0 (2018-11-13) :( UPD: looks like it works (but this is ugly) from pytest_django.fixtures import live_server as orig_live_server
live_server = pytest.fixture(scope='function')(orig_live_server.__wrapped__) |
I have had some success with the code below, but (YMMV)
|
I'm running into this too. No doubt all the above variants of the fix will work. But I'm wondering: what is the correct behavior here? It seems like, the root problem is actually those AJAX requests still happening after the test finishes. Rightly so, they should prevent the database from flushing. Think about it in real life and not a test. If you had a DB and wanted to run a flush command, and had a ton of active requests towards that table, wouldn't you expect an error or to have to handle it, rather than it just working and magically killing all those pending requests? I can think of a few options:
|
I'm not sure if I'm running into this problem or if it is just a well known issue that the docs are hinting at, but after I request a 'live_server' fixture for a test, I do not get the normal db fixture (which I've overloaded to ingest a file of test data) on subsequent tests. I tried mmcardle's suggested wrapper for re-scoping live_server down to 'function', but the problem remained. Putting all live_server tests last is sort of doable with alphabetically ordering the test filenames, but don't feel great about tests that work in one order and not another. |
If the above fixes do not work for anyone else, try temporarily disabling the --reuse-db option (usually in your pytest.ini file) and running the test(s). If it no longer errors, add the --reuse-db option back. |
Are there any new developments or better workaround? |
The
live_server
fixture is session-scoped while thetransactional_db
fixture (whichlive_server
implicitly enables) is function-scoped.As a consequence,
live_server
can handle requests during the whole duration of the test suite. These requests can collide with the database flushes thattransactional_db
performs after each test or with the periods when access to the database is disabled between two tests.Here's what the sequence of events looks like:
live_server
fixture starts aLiveServerThread
transactional_db
fixture runs (triggered by the function-scoped, autouse_live_server_helper
fixture) and addsTransactionTestCase._post_teardown
to finalizerstransactional_db
finalizer runs and attempts to flush the database, conflicting with the requests the live server is still processinglive_server
finalizer waits forLiveServerThread
to terminateThe conflict can cause deadlocks between any SQL query from a HTTP request handled by the live server and the query that flushes the database, which looks like this:
This failure mode is particularly annoying because the database isn't flushed, requiring to next test run to re-create the database and thus negating the benefits of
--reuse-db
.If database reuse isn't enabled, destroying the test database can fail with:
I've also seen SQL queries from HTTP requests handled by the live server to fail with:
because the
transactional_db
finalizer has flushed the database and blocked access until the next test.I'm planning to look for workarounds and will update this ticket with my findings.
The text was updated successfully, but these errors were encountered: