1 files changed, 27 insertions, 0 deletions
diff --git a/packages/meshbay-hub/tests/conftest.py b/packages/meshbay-hub/tests/conftest.py
index 2769f7e..cb595c5 100644
--- a/packages/meshbay-hub/tests/conftest.py
+++ b/packages/meshbay-hub/tests/conftest.py
@@ -96,3 +96,30 @@ def _skip_email_verification(monkeypatch):
     monkeypatch.setattr(
         "meshbay_hub.api.users._create_and_send_verification", _noop)
     monkeypatch.setattr("meshbay_hub.mail._send", lambda msg: True)
+
+
+@pytest.fixture(autouse=True)
+def _no_cleanup_task(monkeypatch):
+    """
+    Do not run the maintenance loop under test.
+
+    `create_app`'s lifespan starts `cleanup_loop` as an asyncio task, so every
+    test — each of which enters that lifespan — ran a purge pass concurrently
+    with its own requests. On SQLite `:memory:` that is not merely noisy: the
+    engine uses a **StaticPool**, one connection for the whole process, so the
+    request's session and the cleanup task's session interleave their
+    transactions on the *same* connection. A registration could commit and then
+    not be visible to the login three lines later, which surfaced as
+    `401 Invalid credentials` for an account created moments before, in about
+    one run of `test_node_ws_auth.py` in four.
+
+    The purge itself is not at fault and this is not a production condition:
+    the DELETE was measured removing 0 rows, and PostgreSQL gives every session
+    its own connection. What is removed here is the second user of the shared
+    one. Tests that want the maintenance behaviour call the `purge_*` functions
+    directly, which is how they are covered.
+    """
+    async def _noop(get_session):
+        return
+
+    monkeypatch.setattr("meshbay_hub.tasks.cleanup.cleanup_loop", _noop)