-
Notifications
You must be signed in to change notification settings - Fork 345
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
When running pytest on a database with --reuse-db where python manage.py migrate was already run, cause failure on old runpython #756
Comments
note that it does not seem to be deterministic (I've removed --reuse-db and it passed once in CI, and now it does not work anymore, and our CI are on aws spot instances, which mean they are recycled pretty often, so we don't have any dangling state between two CI run) |
Use Use I also suggest trying to debug this locally, where you can better add breakpoints etc.. ;) |
I will try |
I would expect What Django version are you using, and what kind of DB? |
postgresql 10 and django 1.11 , python3.6 |
Also note that it will be run for the first usage of This is the current behavior: diff --git i/tests/test_db_setup.py w/tests/test_db_setup.py
index 0b3d516..ba96b14 100644
--- i/tests/test_db_setup.py
+++ w/tests/test_db_setup.py
@@ -406,3 +406,17 @@ class Migration(migrations.Migration):
)
assert result.ret == 0
result.stdout.fnmatch_lines(["*mark_migrations_run*"])
+
+ # Runs migration with first "--reuse-db" usage.
+ result = testdir.runpytest_subprocess(
+ "--reuse-db", "--tb=short", "-v", "-s"
+ )
+ assert result.ret == 0
+ assert "mark_migrations_run" in result.stdout.str()
+
+ # Does not run them on second "--reuse-db" usage.
+ result = testdir.runpytest_subprocess(
+ "--reuse-db", "--tb=short", "-v", "-s"
+ )
+ assert result.ret == 0
+ assert "mark_migrations_run" not in result.stdout.str() (with this test: https://github.com/blueyed/pytest-django/blob/37b9216655baa21ae4ccf0b28069c07eb4473cb3/tests/test_db_setup.py#L356-L408) |
ok right now i'm focusing on the "without --reuse-db" as here the behaviour should be always consistent (i.e DROP database, and recreate everything) , and even here I'm seeing the bug i'm describing what is weird is that, the RunPython seems to be run in the correct order of their migrations, and then pytest starts to run the actual tests, but then all the following tests are reporting "ERROR" with the same stacktrace that is in the migration as if the migration was run N time , but the print I added in RunPython code directly only appears once at migration time not at test time |
currently (still without --reuse-db) I seem to be able to trigger the bug if
however at the migration step, I see far less migration being applied than I actually have (they are still run in order though) then migrations steps stop and the tests start to run, and the first tests are in Errror, and actually they contains the stack trace of the last migration that run. i.e it tries to run migrations, one of these migrations fails with an exception, (due to the diff postgres schema / django model at the point in time) it goes directly to running the test and only there it shows the exceptions (and duplicated) what is even weirder is that some tests still succeed (but a very low minority) |
I start to wonder if it's due to the fact I have two database, "default" and "read-only" (in test they both actually correspond to the same database) and I wonder if there's some kind of race condition that RunPython are not run on "read-only" on which the drop database is done (but pytest-django do the magic test_%s ) but run on "default" that is still in database "vagrant" that has not been dropped ? |
It seems to be that during the migrations sometimes "default" is chosen, sometimes "readonly" is chosen if I add in
I got for the following migration :
the following output
if I run a second time i got
|
ok ok so I think i finally found the solution so using ['TEST']['MIRROR'] = 'default' seems to fix the problem however I think ( I don't know how easy to it is to implement) that if pytest-django does explicitly not support several databases it should:
what do you think ? anyway thanks for your help, it really helped me to be on the right track :) |
I've not read up on your comments yet, but do you use |
git grep transactional_db returns 0 result in my codebase |
There are other ways to use it, e.g. with a However, your investigation appears to be spot on. Not sure currently though what we can do about it, and if Django would behave the same (i.e. then it would not really be a bug in pytest-django, but just something we could help with, but maybe we're using Django's internals not correctly here). See also #76 and https://github.com/pytest-dev/pytest-django/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+multiple+databases. It would be great to have this improved/fixed indeed. |
I explain myself,
I have a project with a lot of migrations, with 3 important migrations for our case (in that order):
foo
to the modelBar
foo
now if i first do
I finish with a database without field
foo
=> normal and expectedif I then run
pytest --reuse-db
I will got SQL failure because pytest re-runs all migrations, but without actually replaying the changes on the database , but only running the RunPython, so the RunPython of 2) is run on database were the field has already been removedis it a known behaviour , if so why ?
I would have thought that it would see migrations has been run , and will not execute anything, runpython included
The text was updated successfully, but these errors were encountered: