Repository navigation
Conversation
TestPutResurrection checks the global WarnCount. It failed when it ran right after TestUpdateHeartbeatDocClusterAwareTransientError: [WRN] t:TestUpdateHeartbeatDocClusterAwareTransientError/startup Failed to update background manager status in periodic polling: this Rosmar bucket has been closed, will retry - The startup subtest closed the bucket before it stopped the manager. - Stop does not wait, so the status poller kept running. - Other background manager tests had the same pattern. Fix: - Add synchronousStop. It stops the manager and waits for it to finish. - Use it in the background manager tests before the bucket closes. - Close the leaky bucket in a t.Cleanup that runs after the manager stops. Not the final fix: - Nothing tracks the run goroutine or the heartbeat loop. - Tracking them in BackgroundManager would let callers wait directly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
An unconditional stop can recreate a deleted heartbeat during terminal cleanup, causing the removal wait to exceed its default 10-second timeout.
1 open issue
What changed in this PR
This test-only PR reduces background-manager cleanup races that can produce bucket-closed warnings and affect later tests’ global warning-count assertions.
Changes:
- Add a stop helper that waits for terminal state, persisted status, and single-node heartbeat removal.
- Use the helper across background-manager tests and close the leaky bucket after manager cleanup.
- Release the resync options read lock before deferred shutdown.
| File | Description |
|---|---|
db/util_testing.go |
Add synchronous stop helper and align heartbeat-removal timeout with other state-transition waits. |
db/background_mgr_test.go |
Wait for manager cleanup and correct bucket-close ordering. |
db/background_mgr_resync_dcp_test.go |
Wait for standalone managers to stop and narrow the options read-lock scope. |
Review effort: Balanced
Contributor
|
Droid finished @torcolvin's task —— View job Validated all candidates (none provided). No new inline review comments to post for this PR. 0 inline comments posted |
bbrks
approved these changes
Nov 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

CBG-6075: (test-only) wait for background managers to stop before closing the bucket
TestPutResurrectionchecks the global WarnCount. It failed when it ran right afterTestUpdateHeartbeatDocClusterAwareTransientError:There were several problems:
t.Cleanupanddefer.BackgroundManager.Stopis not synchronous does not wait, so the status poller kept running after it was called while the bucket was deleted.Fix:
synchronousStop. It stops the manager and waits for it to finish.Not the final fix:
DatabaseContext.Closewhere even single node background managers don't actually wait for stopping and their final status updates might also fail. This is less likely just due to the timing of how long it takes theDatabaseContext.Close. This will be thought about in a BackgroundManager refactor.Pre-review checklist
base.UD(docID),base.MD(dbName))docs/apiIntegration Tests