From 6b145d7aad276b27232b9b890a10031615a013e4 Mon Sep 17 00:00:00 2001 From: arc53-machine <232052973+arc53-machine@users.noreply.github.com> Date: Wed, 23 Sep 2026 23:23:41 +0100 Subject: [PATCH] Wait for the background trace write in the /v1 replay test The first request's trace is written on the trace-writer pool after the response returns; assert once it has landed rather than racing it. --- tests/api/v1/test_v1_idempotency.py | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tests/api/v1/test_v1_idempotency.py b/tests/api/v1/test_v1_idempotency.py index eda35b4d..7715a886 100644 --- a/tests/api/v1/test_v1_idempotency.py +++ b/tests/api/v1/test_v1_idempotency.py @@ -19,6 +19,7 @@ These tests pin both layers against an ephemeral Postgres (``pg_engine``): from __future__ import annotations +import time import uuid from contextlib import contextmanager from typing import Any, Dict, List @@ -478,5 +479,12 @@ class TestV1ReplayTrace: resp2 = _post_chat(c, self.QUESTION, api_key, idem_key=idem_key) assert resp1.status_code == resp2.status_code == 200 + # The first request's trace is written on the background writer, so + # wait for it. A replay's trace is dropped synchronously, and an + # unclaimed-trace flush would be synchronous too, so any stray write + # is already in ``written`` by the time the responses return. + deadline = time.monotonic() + 5 + while not written and time.monotonic() < deadline: + time.sleep(0.02) # Only the first request's trace is written, and it is not a failure. assert [t.status for t in written] == ["ok"]