Flaky test: test_concurrent_requests_have_unique_request_ids fails on Python 3.13

[Besthope-Official]

Problem

test_concurrent_requests_have_unique_request_ids in tests/integration/test_audit_request_tracing.py:212 intermittently fails on Python 3.13 CI. The test fires 5 concurrent requests via asyncio.gather and asserts len(request_ids) >= 5, but aiosqlite drops a write under concurrency on the in-memory SQLite database, resulting in only 4 records.

Minimal Reproducible Example

for i in {1..300};do echo run $i; uv run --python 3.13 --frozen pytest --cov -q tests/integration/test_audit_request_tracing.py::test_concurrent_requests_have_unique_request_ids||break;done

Expected vs Actual

Expected: 5 audit log entries with unique request_id values.

Actual: Only 4 entries written. aiosqlite's _connection_worker_thread raises RuntimeError: Event loop is closed during concurrent writes, causing a silent audit log loss.

Environment

• Python version: 3.13 (passes on 3.12)
• CI run: https://github.com/SingularityLab-SWUFE/fastapi-template-agent/actions/runs/21795701103/job/62882818397?pr=128
• DB: SQLite :memory: via aiosqlite

[Besthope-Official]

Additional Context: Event loop is closed Annotations

The test (3.13) job produced multiple Event loop is closed annotations from aiosqlite's _connection_worker_thread:

PytestUnhandledThreadExceptionWarning: Exception in thread Thread-11 (_connection_worker_thread)

  File "aiosqlite/core.py", line 66, in _connection_worker_thread
    future.get_loop().call_soon_threadsafe(set_result, future, result)
  File "asyncio/base_events.py", line 878, in call_soon_threadsafe
    self._check_closed()
  File "asyncio/base_events.py", line 556, in _check_closed
    raise RuntimeError('Event loop is closed')

Affected tests:

• tests/cache/test_local_cache.py::test_set_with_ttl
• tests/test_handlers.py::test_handler_returns_unified_response_for_http_exception[400-...]
• tests/test_handlers.py::test_handler_returns_unified_response_for_http_exception[422-...]

aiosqlite's background thread attempts to call back into the event loop after it has already closed. The test (3.12) job also has some Event loop is closed annotations but tests pass, suggesting Python 3.13 enforces stricter event loop lifecycle management. This shares the same root cause as the flaky concurrent write test.