[Bug]: MongoDb WaitIndicateReadiness counts log lines from the previous run, so a restarted container either hangs or is reported ready too early

[arnelirobles]

Testcontainers version

4.11.0 (develop, 1d329ad1)

Using the latest Testcontainers version?

Yes

Host OS

macOS

Host arch

arm64

.NET version

10

Docker version

Docker Desktop, engine 28.x

What happened?

WaitIndicateReadiness in MongoDbBuilder is not safe across a container restart, in both directions.

// src/Testcontainers.MongoDb/MongoDbBuilder.cs
public async Task<bool> UntilAsync(IContainer container)
{
    var (stdout, stderr) = await container.GetLogsAsync(since: container.StoppedTime, timestampsEnabled: false)
        .ConfigureAwait(false);

    return _count.Equals(Array.Empty<string>()
        .Concat(stdout.Split(LineEndings, StringSplitOptions.RemoveEmptyEntries))
        .Concat(stderr.Split(LineEndings, StringSplitOptions.RemoveEmptyEntries))
        .Count(line => line.Contains("Waiting for connections")));
}

_count is 1 or 2 depending on whether credentials are configured, and the comparison is exact equality over the logs since StoppedTime. After a restart that window covers the previous run as well as the new one, so:

• Too many matches: the start hangs. The count exceeds _count and the equality can never become true. For a replica set container this surfaces inside InitiateReplicaSetAsync, which awaits this readiness check before initiating. The default wait strategy timeout is one hour, so the caller appears to hang rather than fail.

• Too few matches, at the wrong time: the start returns early. A single stale Waiting for connections line from the previous run can satisfy the check before the new mongod is listening. The next command then fails with MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017.

Steps to reproduce

Add a restart test to MongoDbContainerTest:

[Fact]
public async Task RestartsSuccessfully()
{
    using var cts = new CancellationTokenSource(TimeSpan.FromMinutes(2));

    await _mongoDbContainer.StopAsync(cts.Token);
    await _mongoDbContainer.StartAsync(cts.Token);

    var execResult = await _mongoDbContainer.ExecScriptAsync("db.adminCommand({ping:1}).ok;", cts.Token);
    Assert.True(0L.Equals(execResult.ExitCode), execResult.Stderr);
}

Observed across the existing fixtures:

Fixture	Result
MongoDbNoAuthConfiguration	fails in ~3s, MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017
MongoDbReplicaSetDefaultConfiguration	hangs until the bound, TimeoutException from WaitStrategy.WaitUntilAsync via InitiateReplicaSetAsync
MongoDbNamedReplicaSetConfiguration	same as above
MongoDbV5Configuration	same as above
MongoDbDefaultConfiguration, MongoDbV4Configuration	pass

Expected result / actual result

Expected: a stopped container that is started again becomes ready, and the readiness check reflects the current run.

Actual: the readiness check counts log lines from the previous run, so a restart either hangs until the wait strategy times out or is reported ready before mongod is accepting connections.

Additional information

Two things worth deciding together:

1. Comparing with >= instead of exact equality would fix the hang but not the early return, since a stale line still counts.
2. Scoping the log window to the current run (rather than StoppedTime, which refers to the previous stop) addresses both, but I am not sure what the intended semantics of StoppedTime are here.

Found while working on #1722; deliberately kept out of that pull request since it is a separate defect. Happy to open a PR once the preferred direction is clear.

[coderabbitai]

🔗 Related PRs

#1585 - fix(Milvus): Use healthcheck wait strategy [merged]
#1593 - fix(Elasticsearch): Use HTTP wait strategy [merged]
#1624 - fix(EventHubs): Workaround health API timeout [merged]
#1656 - fix(MongoDb): Wait for post-init startup readiness before replica set initiation [merged]
#1679 - fix(Nats): Use healthz API for readiness probe [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[aradalvand]

I just encountered this exact problem and was about to file a duplicate.

[xamir82]

Same analysis on our side — two things to add.

This is a regression; first affected release is 4.11.0. WaitIndicateReadiness used to apply only to the non-replica-set path. Decompiling the
shipped assemblies, InitiateReplicaSetAsync has only the rs.initiate() wait in 4.8.1 and 4.10.0, and gains the readiness check in 4.13.0.

#1656 is what put it on the replica-set path, landing between the 4.10.0 and 4.11.0 releases. So pinning Testcontainers.MongoDb to ≤ 4.10.0 avoids this code path entirely in the meantime.

It doesn't require a restart. The container below is started once and never stopped, so StoppedTime isn't involved — any log content that makes
the marker appear more often than expected is enough:

var container = new MongoDbBuilder("mongo:8.0")
    .WithReplicaSet()
    .WithResourceMapping(
        Encoding.Default.GetBytes("#!/bin/bash\necho 'Waiting for connections'\necho 'Waiting for connections'\n"),
        "/docker-entrypoint-initdb.d/00-extra-marker.sh",
        0u, 0u, (UnixFileModes)493)
    .Build();

await container.StartAsync();

With two echos the count goes 1 → 3, never 2, and this fails every run. With one echo the count still ends at 3, but the outcome varies between runs. It depends purely on whether the once-per-second poll samples during the window where the count is momentarily 2. So it's a race whenever the final count can differ from the expected one, not just a restart artifact.

[arnelirobles]

Thanks both. I can confirm the regression, and @xamir82's repro rules out one of the two fixes I suggested above, so it is worth correcting that.

On the regression. Confirmed from the history rather than the decompiled assemblies: #1656 (ec6b50f6, merged 2026-03-08) added exactly the ten lines that put WaitIndicateReadiness on the replica-set path, and git tag --contains ec6b50f6 gives 4.11.0 as the first release carrying it. Before that the replica-set path never used the log-counting check at all, so pinning Testcontainers.MongoDb to 4.10.0 does avoid it.

On the repro. This is the important part. My write-up framed the problem as "not restart-safe", but a container that is never stopped reproduces it, so the restart is only one way to reach the state. That invalidates the second of the two directions I listed:

• Scoping the log window to the current run does not fix it. In @xamir82's repro the extra markers are emitted within the current run by an initdb script, so a correctly scoped window still contains them.
• >= instead of exact equality is worse, not just insufficient. With markers appearing early from initdb, >= is satisfied before mongod is accepting connections, which turns the intermittent early-return into a reliable one. That is the ECONNREFUSED failure mode.

The underlying problem is that the check compares a fixed number against a count that only ever grows, over content the module does not control. Any log line containing Waiting for connections counts, whoever wrote it, and whether the check passes depends on when the once-per-second poll happens to sample. There is no threshold that makes that correct.

Suggested direction. Replace the log count with a command probe. The module already has one immediately below it:

// WaitInitiateReplicaSet
private const string ScriptContent = "var r=db.runCommand({hello:1}).isWritablePrimary;quit(r===true?0:1);";

For the pre-initiation readiness that #1656 needed, the equivalent is a plain db.adminCommand({ping:1}), which is true only once mongod is actually serving and is unaffected by log content. That also matches the direction the project has already taken elsewhere: #1585 (Milvus, healthcheck), #1593 (Elasticsearch, HTTP), #1679 (Nats, healthz).

One caveat worth checking before anyone implements it: #1656 exists because the official image starts mongod twice during first-time initialization, and a ping could succeed against the bootstrap process. If it does, the probe needs to distinguish the final process, and the fix is a little more than a swap.

Happy to put up a PR along those lines if that direction looks right. Keeping it separate from #1731, which is only about rs.initiate being non-idempotent.