fix(MongoDb): Treat an already initiated replica set as success - #1731
fix(MongoDb): Treat an already initiated replica set as success#1731arnelirobles wants to merge 1 commit into
Conversation
The startup callback runs on every start, so a reused container runs the replica set initiate script against a set that is already initiated. mongosh throws MongoServerError (code 23, AlreadyInitialized) rather than returning a result, so the script exits non-zero and the wait strategy retries it until it times out. The default timeout is one hour, so the caller appears to hang. Catch that error and exit zero, which makes the callback idempotent. Adds a reuse test that starts the same replica set container twice. It times out before this change and completes in a few seconds after it.
✅ Deploy Preview for testcontainers-dotnet ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughMongoDB replica-set initialization now succeeds when MongoDB reports ChangesMongoDB replica-set reuse
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fixes #1722
The problem
UnsafeStartAsyncinvokes the startup callback on every start, so a reused container runsInitiateReplicaSetAsyncagainst a replica set that is already initiated.The script it runs is not idempotent:
On a set that already exists,
rs.initiatethrows rather than returning a result, sovar ris never assigned and mongosh exits non-zero:WaitStrategy.WaitUntilAsyncthen retries the script on its interval. The default wait strategy timeout is one hour, which is why the reporter saw the samemongoshexec repeat "without ever resolving".The fix
Catch the error and treat
AlreadyInitializedas success, so the startup callback is idempotent:Any other server error still exits non-zero and is still retried, so a genuinely failing initiation behaves as before.
Testing
MongoDbReplicaSetReuseTest.ReusedContainerStartsAgainstarts the same replica set container twice withWithReuse(true), asserts the second start reused the first container, and asserts the replica set is healthy afterwards.Testcontainers.MongoDb.Testssuite: 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:It asserts the count is exactly 1 or 2 over logs taken since
StoppedTime, which is not restart-safe in either direction:_countand the equality can never hold. The container start hangs.mongodis listening, so the start returns early and the next command fails withMongoNetworkError: 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
Tests