event loop flaky test suite: second fix tentative

[polmichel]

Why

CI occasionally fails with RuntimeError: Event loop is closed during test_client teardown (example).

#9022 added a stderr dump, but it runs after redis-py's Connection.disconnect() finally: clause nulls _writer/_reader. The dump shows writer=None loop=None. Therefore, the loop the writer was actually bound to is hidden. This is the one fact we need to identify the offender (Prefect worker loop? executor loop? asyncio.run site?).

What

Test-only additions on top of #9022 and no production code changes.

Additional information

When redis-py creates a new connection, we now record a snapshot of context against the connection itself: an identifier and a short textual description of the event loop the writer was bound to, the name of the thread the connect ran on, and a small call stack pointing at whatever code triggered the connect.

Loop mismatch detection

When a pool is disconnected we also intercept the call. If any pooled connection was created on a different loop than the one currently running, we log a divergence line per connection.

Loop human friendly label registry

Finally, a small registry maps loop identifiers to human-readable labels, with the pytest-asyncio session loop tagged once at startup. Both dump paths consult the registry so a divergence between two loops shows up as named subsystems rather than two opaque integers.

Installation runs once per test session via an autouse fixture and is safe to call repeatedly.

What the next CI hit will show

Two stderr blocks instead of one:

• Pre-disconnect — a divergence block listing every connection whose creation loop is not the current loop, with the loop id, the registry label if known, the loop's textual description, the thread the connect ran on, and an indented call-stack sub-block.
• Post-mortem — the existing dump, now annotated per connection with the same set of creation-time fields, plus a top-level line naming the current loop's id, label, and closed state.

What actually identifies the owner of an orphaned writer:

• The registry label, when the foreign loop matches a known subsystem.
• The thread name, which usually distinguishes a Prefect worker, an executor pool worker, and the main thread.
• The captured call stack, which points at the synchronous awaiter of the connect.
• The loop id and textual description

Example pre-disconnect output (loop divergence case)

Redis pool disconnect loop divergence detected:
  _available_connections: conn=4391928112 creation_loop=4391851520 creation_loop_label=None creation_loop_repr='<_UnixSelectorEventLoop running=False closed=True debug=False>' creation_thread='ThreadPoolExecutor-0_0' current_loop=4399238400 current_loop_label='pytest-session'
    creation_stack:
      File ".../prefect/utilities/asyncutils.py", line 213, in run_coro_as_sync
        return call.result()
      File ".../prefect/_internal/concurrency/calls.py", line 312, in result
        return self.future.result(timeout=timeout)
      File ".../infrahub/services/adapters/cache/redis.py", line 41, in get
        result = await self._client.get(key)
      File ".../redis/asyncio/client.py", line 612, in execute_command
        conn = await self.connection_pool.get_connection(...)

If every pooled connection's creation loop matches the current loop, nothing is printed.

To delete once the flakiness is identified and fixed.

[polmichel]

Not clean, but this code will be hopefully removed soon

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing pmi-20260429-flaky-test-event-loo (5c4ef78) with stable (9ab7bfb)¹}

Footnotes

1. No successful run was found on stable (34251a9) during the generation of this report, so fb134fb was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩