fix(test): stop Redis fixture aborting on first connection attempt

[alexeyzimarev]

The Redis test fixture connects immediately after the container reports ready, and the first ConnectionMultiplexer.Connect occasionally races the server: the whole fixture initialization fails with RedisConnectionException before any test logic runs, taking down random tests in the suite. Reproduced locally roughly once per 5–10 suite runs.

abortConnect=false (as the exception message itself suggests) makes the multiplexer keep retrying in the background instead of aborting on the first failed attempt. With this change the suite passed five consecutive full runs.

Split out of #568 per the focused-PR guideline.

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Prevent Redis test fixture failure during container startup

🐞 Bug fix 🧪 Tests 🕐 Less than 5 minutes

AI Description

• Keeps the Redis multiplexer retrying when container readiness races server availability.
• Prevents intermittent fixture initialization failures before Redis integration tests execute.

Diagram

sequenceDiagram
    participant F as Test Fixture
    participant C as Redis Container
    participant M as Redis Multiplexer
    participant R as Redis Server
    F->>C: Start container
    C-->>F: Ready reported
    F->>M: Connect abort=false
    M->>R: Initial connection
    alt Server still starting
        R--xM: Connection refused
        M->>R: Retry connection
    end
    R-->>M: Connected
    M-->>F: Redis database

Loading

High-Level Assessment

Using StackExchange.Redis's built-in abortConnect=false behavior is the most focused approach. Explicit retry loops or additional container readiness polling would duplicate connection-management behavior and add test infrastructure complexity.

Files changed (1) +3 / -1

Bug fix (1) +3 / -1

IntegrationFixture.csKeep Redis connections retrying during fixture startup +3/-1

Keep Redis connections retrying during fixture startup

• Adds 'abortConnect=false' to the test fixture's Redis connection configuration. The multiplexer can now retry when container readiness precedes actual server availability instead of failing fixture initialization immediately.

src/Redis/test/Eventuous.Tests.Redis/Fixtures/IntegrationFixture.cs

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Connect remains synchronous I/O ✓ Resolved 📘 Rule violation ➹ Performance

Description

The modified fixture still uses the blocking ConnectionMultiplexer.Connect network API inside
InitializeAsync. This violates the requirement that I/O use async APIs with .NoContext().

Code

src/Redis/test/Eventuous.Tests.Redis/Fixtures/IntegrationFixture.cs[42]

+            var muxer = ConnectionMultiplexer.Connect($"{connString},allowAdmin=true,abortConnect=false");

Evidence

PR Compliance ID 1 prohibits synchronous network calls and requires awaited I/O to use
.NoContext(). The changed line invokes the synchronous ConnectionMultiplexer.Connect API rather
than awaiting ConnectAsync.

CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false): CLAUDE.md: All I/O Code Must Be Async and Use NoContext for ConfigureAwait(false)
src/Redis/test/Eventuous.Tests.Redis/Fixtures/IntegrationFixture.cs[40-42]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Replace the synchronous Redis connection with asynchronous connection initialization and apply the repository's `.NoContext()` convention.
## Issue Context
The fixture initialization performs network I/O through `ConnectionMultiplexer.Connect`, which blocks despite being called from an async method. Preserve `abortConnect=false` so initial connection failures continue retrying.
## Fix Focus Areas
- src/Redis/test/Eventuous.Tests.Redis/Fixtures/IntegrationFixture.cs[40-44]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

Test Results

 46 files  + 24   46 suites  +24   12m 16s ⏱️ -15s
373 tests +  4  373 ✅ +  4  0 💤 ±0  0 ❌ ±0 
700 runs  +320  700 ✅ +320  0 💤 ±0  0 ❌ ±0 

Results for commit 69a26a6. ± Comparison against base commit 3cb68c2.

This pull request removes 5 and adds 9 tests. Note that renamed tests count towards both.

Eventuous.Tests.Azure.ServiceBus.IsSerialisableByServiceBus ‑ Passes(08/03/2026 14:31:31 +00:00)
Eventuous.Tests.Azure.ServiceBus.IsSerialisableByServiceBus ‑ Passes(08/03/2026 14:31:31)
Eventuous.Tests.Azure.ServiceBus.IsSerialisableByServiceBus ‑ Passes(d6ea070b-8d6b-46d6-9e04-bb9b4acedc59)
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 4, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-03T14:31:52.5505416+00:00 })
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 8, Timestamp: 2026-08-03T14:31:52.5505416+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-03T14:31:52.5505416+00:00 })

Eventuous.Tests.Azure.ServiceBus.IsSerialisableByServiceBus ‑ Passes(08/19/2026 13:49:54 +00:00)
Eventuous.Tests.Azure.ServiceBus.IsSerialisableByServiceBus ‑ Passes(08/19/2026 13:49:54)
Eventuous.Tests.Azure.ServiceBus.IsSerialisableByServiceBus ‑ Passes(fe24a153-9f51-48e4-b598-24a7878ecbdd)
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 4, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:40.0402638+00:00 })
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 8, Timestamp: 2026-08-19T13:45:40.0402638+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:40.0402638+00:00 })
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 4, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:41.0767066+00:00 })
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 8, Timestamp: 2026-08-19T13:45:41.0767066+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:41.0767066+00:00 })
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 4, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:42.9337572+00:00 })
Eventuous.Tests.Subscriptions.SequenceTests ‑ ShouldReturnFirstBefore(CommitPosition { Position: 0, Sequence: 1, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 6, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 8, Timestamp: 2026-08-19T13:45:42.9337572+00:00 }, CommitPosition { Position: 0, Sequence: 2, Timestamp: 2026-08-19T13:45:42.9337572+00:00 })

[alexeyzimarev]

Addressed the Qodo finding: the fixture now awaits ConnectionMultiplexer.ConnectAsync instead of calling the synchronous Connect inside InitializeAsync. Went one step further while at it — the multiplexer is now created once and shared by all tests (instead of a new connection per GetDatabase() call) and disposed with the fixture, which is how StackExchange.Redis is meant to be used and removes the connection churn entirely. abortConnect=false and allowAdmin=true are preserved. Redis suite passed four consecutive full runs with the change.