[Django] #33356: "python manage.py test" fails, but running the individual TestCase pass
Django
-----------------------------------------+------------------------
Reporter: Dylan Yung | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
There's some weird internal Django bug with views that use
"transaction.atomic()" if you ping that view with multiple TestCase a
weird bug will happen where there's a DB check at the end of tests after
the DB has been torn down. I made 2 StackOverflow posts regarding this
issue and found the fix as well. Hopefully there'll be an internal fix.
https://stackoverflow.com/questions/70105907/django-full-test-suite-
failing-when-adding-a-testcase-but-full-test-suite-pas/70312267#70312267
https://stackoverflow.com/questions/70166752/django-serializer-throwing-
invalid-pk-object-does-not-exist-when-setting-m
--
Ticket URL: <https://code.djangoproject.com/ticket/33356>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Dylan Yung | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Dylan Yung:
Old description:
> There's some weird internal Django bug with views that use
> "transaction.atomic()" if you ping that view with multiple TestCase a
> weird bug will happen where there's a DB check at the end of tests after
> the DB has been torn down. I made 2 StackOverflow posts regarding this
> issue and found the fix as well. Hopefully there'll be an internal fix.
>
> https://stackoverflow.com/questions/70105907/django-full-test-suite-
> failing-when-adding-a-testcase-but-full-test-suite-pas/70312267#70312267
> https://stackoverflow.com/questions/70166752/django-serializer-throwing-
> invalid-pk-object-does-not-exist-when-setting-m
New description:
There's some weird internal Django bug with views that use
"transaction.atomic()" if you ping that view with multiple TestCase a
weird bug will happen where there's a DB check at the end of tests after
the DB has been torn down. I made 2 StackOverflow posts regarding this
issue and found the fix as well. Hopefully there'll be an internal fix.
Because Django tests the db transaction processing mechanism, the real
test part is finish and success, and then it will rollback the data（data
flush),so some db level check is no use and misleading.
so we need modify the foreign key check defer to make it get right result.
https://stackoverflow.com/questions/70105907/django-full-test-suite-
failing-when-adding-a-testcase-but-full-test-suite-pas/70312267#70312267
https://stackoverflow.com/questions/70166752/django-serializer-throwing-
invalid-pk-object-does-not-exist-when-setting-m
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33356#comment:1>
Django
Reporter: Dylan Yung | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Dylan Yung:
Old description:
> There's some weird internal Django bug with views that use
> "transaction.atomic()" if you ping that view with multiple TestCase a
> weird bug will happen where there's a DB check at the end of tests after
> the DB has been torn down. I made 2 StackOverflow posts regarding this
> issue and found the fix as well. Hopefully there'll be an internal fix.
>
> Because Django tests the db transaction processing mechanism, the real
> test part is finish and success, and then it will rollback the data（data
> flush),so some db level check is no use and misleading.
>
> so we need modify the foreign key check defer to make it get right
> result.
>
> https://stackoverflow.com/questions/70105907/django-full-test-suite-
> failing-when-adding-a-testcase-but-full-test-suite-pas/70312267#70312267
> https://stackoverflow.com/questions/70166752/django-serializer-throwing-
> invalid-pk-object-does-not-exist-when-setting-m
New description:
There's some weird internal Django bug with views that use
"transaction.atomic()" if you ping that view with multiple TestCase a
weird bug will happen where there's a DB check at the end of tests after
the DB has been torn down. I made 2 StackOverflow posts regarding this
issue and found the fix as well. Hopefully there'll be an internal fix.
Because Django tests the db transaction processing mechanism, the real
test part is finish and success, and then it will rollback the data（data
flush),so some db level check is no use and misleading.
so we need modify the foreign key check defer to make it get right result.
https://stackoverflow.com/questions/70105907/django-full-test-suite-
failing-when-adding-a-testcase-but-full-test-suite-pas/70312267#70312267
https://stackoverflow.com/questions/70166752/django-serializer-throwing-
invalid-pk-object-does-not-exist-when-setting-m
I'm using a postgres DB
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33356#comment:2>
Django
Reporter: Dylan Yung | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.2
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 Egor R):
* cc: Egor R (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33356#comment:3>
Django
Reporter: Dylan Yung | Owner: nobody
Component: Uncategorized | Version: 3.2
Severity: Normal | Resolution: needsinfo
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 Tim Graham):
* status: new => closed
* resolution: => needsinfo
Comment:
It's not clear to me that Django is at fault. The accepted answer on
Stackoverflow says, "There's some weird internal bug where if you operate
on one table a lot with a lot of different TestCase classes then it'll do
a DB check at the end after it's been torn down and it'll cause an error."
but it's not clear that this is just speculation.
You need to at least provide a far simpler minimal example to reproduce
the problem, and ideally, explain why Django is at fault. Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/33356#comment:4>