Investigate functional test warnings

Nobody has claimed this yet.

Why are we doing this?

While running the functional tests locally, I noticed repeated PytestUnhandledThreadExceptionWarning warnings caused by Django's default SQLite database connection being accessed from a different thread during request cleanup.

Example warning output

=============================== warnings summary ===============================
opencodelists/tests/functional/test_build_codelist.py::test_build_dmd_codelist_single_search[chromium-org_user-Test University-search1-False]
  /opt/venv/lib/python3.12/site-packages/_pytest/threadexception.py:58: PytestUnhandledThreadExceptionWarning: Exception in thread Thread-74 (process_request_thread)
  
  Traceback (most recent call last):
    File "/usr/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
      self.run()
    File "/usr/lib/python3.12/threading.py", line 1010, in run
      self._target(*self._args, **self._kwargs)
    File "/opt/venv/lib/python3.12/site-packages/django/core/servers/basehttp.py", line 103, in process_request_thread
      super().process_request_thread(request, client_address)
    File "/usr/lib/python3.12/socketserver.py", line 696, in process_request_thread
      self.shutdown_request(request)
    File "/usr/lib/python3.12/socketserver.py", line 516, in shutdown_request
      self.close_request(request)
    File "/opt/venv/lib/python3.12/site-packages/django/core/servers/basehttp.py", line 110, in close_request
      self._close_connections()
    File "/opt/venv/lib/python3.12/site-packages/django/core/servers/basehttp.py", line 107, in _close_connections
      connections.close_all()
    File "/opt/venv/lib/python3.12/site-packages/django/utils/connection.py", line 85, in close_all
      conn.close()
    File "/opt/venv/lib/python3.12/site-packages/django/utils/asyncio.py", line 26, in inner
      return func(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^
    File "/opt/venv/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py", line 223, in close
      self.validate_thread_sharing()
    File "/opt/venv/lib/python3.12/site-packages/django/db/backends/base/base.py", line 645, in validate_thread_sharing
      raise DatabaseError(
  django.db.utils.DatabaseError: DatabaseWrapper objects created in a thread can only be used in that same thread. The object with alias 'default' was created in thread id 140254953533568 and this is thread id 140251334846144.
  
  Enable tracemalloc to get traceback where the object was allocated.
  See https://docs.pytest.org/en/stable/how-to/capture-warnings.html#resource-warnings for more info.
    warnings.warn(pytest.PytestUnhandledThreadExceptionWarning(msg))

I thought I'd somehow caused this with the work I'd done on my branch for the BNF import script updates (#3177), but then I checked and found that the same warnings are present on when I run just test-functional on the main branch locally, and in recent functional test CI runs (example 1, example 2, example 3).

I'm not sure why this happens. I'm not sure if it's a known issue in REX. I'm not sure how big of a problem this is (if at all), of it it's something we want to talk more about, potentially investigate or fix. So I thought I'd flag it.

What are we doing?

Initially, just discussing whether anyone is already aware of this, and if we want to do anything about it.

Defining delivery tasks guidance

Run just test-functional on the main branch and inspect the PytestUnhandledThreadExceptionWarning stack shown in the issue, then compare it with the BNF import branch context from #3177. Trace the Django SQLite connection cleanup path named in the warning; done means documenting the cause and agreeing whether a fix or follow-up is needed.

Written by the indexing model from the issue text.

Description

Why are we doing this?

What are we doing?

Contributor guide

First steps

Research direction

Assessment

Investigate functional test warnings

Description

Why are we doing this?

What are we doing?

Contributor guide

First steps

Research direction

Assessment

Get new issues in your inbox