Running a test that uses live_server after a test that uses transactional_db causes database errors

[m-reichle]

Hi all!

I am using python 3.13, sqlite 3.46 and pytest-django 4.8 on Debian Trixie. My test suite uses an sqlite in-memory database.

I am seeing an issue in my test suite where a test that uses playwright-async-pytest and live_server to test some frontend stuff will fail if it is run after a test that uses the transactional_db fixture. The test uses different custom fixtures to log into my Django App, create some DB objects and a playwright browser page that accesses an edit view.

The actual errors that the test fails with vary from run to run. They are all database related though, sometimes an object that should be there isn't, sometimes it exists twice, often there will be session related errors because session data cannot be retrieved from the session cache.

I've done some debugging and from what I can glean there are different connections used during the test's run time.

I've run the same test suite on Debian Bookworm and am not seeing the same issue there. I also see different connections though. My Bookworm suite has python 3.11 and sqlite 3.40, all other versions are the same as in Trixie.

My very vague theory is that the in-memory database get copied/cloned/forked/moved when the test using live_server is set up and there is something going wrong with that particular sqlite version, resulting in different queries ending up on different databases.

I'm afraid my Django-Fu wasn't quite up to digging deeper on this (I've tried, but lost my way in in the db backends), but I'm happy to try any further debugging measures people could recommend to figure this out.

[m-reichle]

I've narrowed this down to the following factors:

• use Debian Trixie (python 3.13, sqlite 3.46)
• use an sqlite in-memory database
• first run a test that uses the transactional_db fixture
• then run a test that uses the live_server fixture and fires a lot of request from the get-go (in my case an HTMX based view that gets assembled from several components)

Doing this will result in a corrupted database for the second test.

My hypothesis would be that something in the extra code that is run for in-memory databases fails with that version of sqlite, but I cannot say for sure. I've switched my tests to using a file-based database as a work-around.