fix(MongoDb): Treat an already initiated replica set as success - #1731

Fixes #1722

The problem

UnsafeStartAsync invokes the startup callback on every start, so a reused container runs InitiateReplicaSetAsync against a replica set that is already initiated.

The script it runs is not idempotent:

var r = rs.initiate({_id:"rs0", members:[{_id:0, host:"127.0.0.1:27017"}]});
quit(r.ok === 1 ? 0 : 1);

On a set that already exists, rs.initiate throws rather than returning a result, so var r is never assigned and mongosh exits non-zero:

MongoServerError: already initialized
  code: 23
  codeName: 'AlreadyInitialized'

WaitStrategy.WaitUntilAsync then retries the script on its interval. The default wait strategy timeout is one hour, which is why the reporter saw the same mongosh exec repeat "without ever resolving".

The fix

Catch the error and treat AlreadyInitialized as success, so the startup callback is idempotent:

try { var r = rs.initiate({...}); quit(r.ok === 1 ? 0 : 1); }
catch (e) { quit(e.codeName === "AlreadyInitialized" ? 0 : 1); }

Any other server error still exits non-zero and is still retried, so a genuinely failing initiation behaves as before.

Testing

MongoDbReplicaSetReuseTest.ReusedContainerStartsAgain starts the same replica set container twice with WithReuse(true), asserts the second start reused the first container, and asserts the replica set is healthy afterwards.

• Before the change: times out (bounded to 3 minutes in the test so a regression fails rather than hangs).
• After the change: passes in about 7 seconds.
• Full Testcontainers.MongoDb.Tests suite: 19 passed, 0 failed.

The test bounds its own wait because the default wait strategy timeout is one hour; without a bound a regression would stall a CI run rather than fail it.

A related defect, not addressed here

While testing this I first wrote the regression test as a stop/start restart rather than reuse, and hit a different problem in WaitIndicateReadiness:

var (stdout, stderr) = await container.GetLogsAsync(since: container.StoppedTime, timestampsEnabled: false);
return _count.Equals(... .Count(line => line.Contains("Waiting for connections")));

It asserts the count is exactly 1 or 2 over logs taken since StoppedTime, which is not restart-safe in either direction:

• After a restart the window spans the previous and the new boot, so the count exceeds _count and the equality can never hold. The container start hangs.
• A single stale "Waiting for connections" line from the previous run can satisfy the check before the new mongod is listening, so the start returns early and the next command fails with MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017.

I have kept that out of this pull request since it is a separate defect with its own design question, and raised it separately. Happy to pick it up if you would like it fixed the same way.

Summary by CodeRabbit

• Bug Fixes

  • Improved MongoDB replica-set startup when reusing or restarting containers.
  • Recognizes an already-initialized replica set as successful, allowing startup callbacks to run safely.
  • Other initialization failures continue to be reported.

• Tests

  • Added coverage verifying reusable MongoDB replica-set containers can start again successfully and retain replica-set status.
  • Confirmed multiple starts resolve to the same container instance.