Closed boxed closed 2 months ago
I think what happens is that _dj_db_wrapper
saves a copy to the "real implementation", but that misfires in this situation and stores the blocking implementation instead.
If I do this:
if self._real_ensure_connection is None:
assert 'blocking' not in BaseDatabaseWrapper.ensure_connection.__name__
self._real_ensure_connection = BaseDatabaseWrapper.ensure_connection
that assert fails the second run
Success! If I do:
if not hasattr(BaseDatabaseWrapper, '_real_ensure_connection'):
BaseDatabaseWrapper._real_ensure_connection = BaseDatabaseWrapper.ensure_connection
self._real_ensure_connection = BaseDatabaseWrapper._real_ensure_connection
then this bug disappears
I realize this is a bit of an edge case, but there seems to be something off about the cleanup for
pytest.mark.django_db
. If you run pytest twice in the same process all tests that are markeddjango_db
fail with the error reproduced below.A reproduction repo is at https://github.com/boxed/pytest_django_block_db_issue. Run run_pytest_twice.py after initializing a venv with pytest-django, and django.
(The reason I'm doing this is because I'm working on the next version of mutmut, which is looking like it could go ~100 times faster than the current version, but this issue stops me from trying out out iommi)
I have tracked down the exception to
_blocking_wrapper
(which was annoyingly hard because of__tracebackhide__
), but I'm at a bit of a loss as to what my next step is.