fix(Couchbase): Treat an already provisioned cluster as configured - #1736
fix(Couchbase): Treat an already provisioned cluster as configured#1736arnelirobles wants to merge 2 commits into
Conversation
The startup callback runs on every start, so a reused container enters ConfigureCouchbaseAsync with a cluster that is already provisioned. Its first step waits on an unauthenticated GET /pools, which a provisioned node answers with 401, so the wait strategy retries a permanent condition for its full five minute timeout and the start appears to hang at "performing configuration". Send the credentials with that probe so it tests whether the management API is up rather than whether the cluster is unprovisioned, then skip the provisioning requests when an authenticated GET /pools/default returns 200. Measured on community-7.0.2 and 7.6.2, fresh vs provisioned: /pools no-auth 200 / 401 /pools with-auth 200 / 200 /pools/default with-auth 404 / 200 Adds a reuse test that starts the same container three times. It fails before this change with a TimeoutException after 5m23s and passes in 24s after it. Closes testcontainers#1337.
✅ 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 (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughCouchbase readiness checks now authenticate requests and detect provisioned clusters. Configuration skips repeated setup for reused containers. A Linux-only test verifies connectivity and shared container identity across multiple starts. ChangesCouchbase reuse handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CouchbaseBuilder
participant CouchbaseContainer
participant CouchbaseReuseTest
CouchbaseReuseTest->>CouchbaseBuilder: Build reusable container
CouchbaseBuilder->>CouchbaseContainer: Check authenticated readiness
CouchbaseContainer-->>CouchbaseBuilder: Report node and provisioned state
CouchbaseBuilder-->>CouchbaseReuseTest: Complete startup without repeated setup
CouchbaseReuseTest->>CouchbaseContainer: Ping cluster
CouchbaseContainer-->>CouchbaseReuseTest: Return services and container identity
Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/Testcontainers.Couchbase.Tests/CouchbaseReuseTest.cs`:
- Around line 36-37: Update the test flow around Cluster.ConnectAsync so the
Couchbase cluster is disposed in a finally block after the ping assertions
complete, including when an assertion fails. Preserve the existing
container.DisposeAsync cleanup workaround and its ResourceReaper session
configuration.
- Around line 54-55: Update the cluster declaration in the test to use
asynchronous disposal with await using, ensuring the connected Cluster remains
available for PingAsync and is disposed after the test operations complete.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 699e738a-7f37-4a9c-96e7-301110a23ea7
📒 Files selected for processing (5)
src/Testcontainers.Couchbase/CouchbaseBuilder.cssrc/Testcontainers.Couchbase/Usings.cstests/Testcontainers.Couchbase.Tests/CouchbaseReuseTest.cstests/Testcontainers.Couchbase.Tests/Testcontainers.Couchbase.Tests.csprojtests/Testcontainers.Couchbase.Tests/Usings.cs
Closes #1337.
The bug
With
WithReuse(true), the secondStartAsyncnever completes. It stalls atCouchbase container is starting, performing configuration.and eventually fails with aTimeoutException.Root cause, which is not where the issue thread was looking
The discussion assumed the unauthenticated provisioning requests were failing against an already-provisioned cluster. The run never gets that far.
ConfigureCouchbaseAsyncstalls on its very first step:An unprovisioned node answers
/poolswithout credentials. A provisioned one returns 401. So on a reused container the readiness probe can never succeed, and the wait strategy retries a permanent condition for its full five minute budget. The 5m23s failure is that timeout plus the 23s first start.Measured
Both
community-7.0.2(the pinned test image) andcommunity-7.6.2, fresh node versus provisioned node:GET /poolsno credentialsGET /poolswith credentialsGET /pools/defaultno credentialsGET /pools/defaultwith credentials/pools/defaultdoes not exist until the cluster is provisioned, so an authenticated 200 there is an unambiguous "the startup callback has already run against this container".The fix
Two changes, both using the
BasicAuthenticationHeaderthe module already defines:ConfigureCouchbaseAsyncwhen an authenticatedGET /pools/defaultreturns 200.Same shape as #1731: a startup callback that runs on every start has to be idempotent, and a permanent condition should not be handed to a retry loop.
Tests
CouchbaseReuseTeststarts the same container three times and asserts a single distinct container id plus a working cluster ping, followingMongoDbReplicaSetReuseTest.TimeoutExceptionafter 5m23sThe first of the three starts is a normal fresh provisioning, so that path is covered too.
One note on local verification
couchbase:community-7.0.2has nolinux/arm64manifest, so on Apple silicon the test image cannot run natively. Local runs usedcommunity-7.6.2; the 7.0.2 rows in the table above were measured under amd64 emulation and are identical. CI runs amd64, so it will exercise the pinned image normally.Summary by CodeRabbit
Bug Fixes
Tests