-
[NA] [SDK] revert(load): remove test_concurrent_writers_race_stress (#6853)
发布于
2026-05-25 15:39:58 +00:00 The race-stress scenario added in OPIK-6576 / PR #6829 ran reliably
locally but proved too fragile under xdist's 4-worker concurrent load
on the GitHub Actions runner: the worker process was killed by the OS
(at ~225 s, well under the explicit @pytest.mark.timeout(300)) while
three other heavy scenarios — heavy_payload, attachments,
many_traces_one_span_each — ran simultaneously against the same
docker-compose Opik stack on the same 7 GB runner. Reducing thread
count, lowering volume and adding think-time each shifted the failure
mode without resolving it.Remove the scenario for now so the suite stays green in CI. The
underlying intent — catching missing-lock regressions in
BatchManager.flush_ready(OPIK-6444 shape) — is still served by:- the OPIK-6444 unit regression test in
tests/unit/message_processing/batching/test_flushing_thread.py,
which uses a 5 ms flush interval + aggressive probe to catch the
bug deterministically; - the existing
test_concurrent_writers_share_one_clientscenario,
which runs at the production flush interval but with realistic
think-time and 30 threads.
The supporting machinery (
_race_stress_flush_intervalcontext
manager,_RACE_FLUSH_INTERVAL_SECONDSconstant, unused imports of
contextlib/opik.api_objects.opik_client/
opik.message_processing.batching.batch_manager_constuctors/
Iterator/pytest) is also removed.pytest-timeoutand the
1200 s global pytest.ini timeout stay — they're useful hang-guards for
any future scenario regardless of this revert. README scenario table
loses its race-stress row; the other 10 scenarios are unaffected.A more isolated race-detection approach (separate workflow step running
the race-stress scenario serially without xdist) can be revisited in a
focused follow-up if we decide it's worth the maintenance cost.下载附件
- the OPIK-6444 unit regression test in