-
Notifications
You must be signed in to change notification settings - Fork 5.8k
remove jonboulle/clockwork for testing/synctest #14185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18,7 +18,6 @@ import ( | |
| "context" | ||
| "time" | ||
|
|
||
| "github.com/jonboulle/clockwork" | ||
| "github.com/sirupsen/logrus" | ||
|
|
||
| "github.com/docker/compose/v5/pkg/utils" | ||
|
|
@@ -30,7 +29,7 @@ const QuietPeriod = 500 * time.Millisecond | |
| // channel. | ||
| // | ||
| // The returned channel is closed when the debouncer is stopped via context cancellation or by closing the input channel. | ||
| func BatchDebounceEvents(ctx context.Context, clock clockwork.Clock, input <-chan FileEvent) <-chan []FileEvent { | ||
| func BatchDebounceEvents(ctx context.Context, input <-chan FileEvent) <-chan []FileEvent { | ||
|
Comment on lines
31
to
+32
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure if this function is used outside of compose itself, because it's a signature change; if that's a problem, we can perhaps replace it with
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did some research, and it doesn’t appear to be used by any other public GitHub repositories. So I think we’re fine, we’ll include a note about it in the next release. |
||
| out := make(chan []FileEvent) | ||
| go func() { | ||
| defer close(out) | ||
|
|
@@ -49,13 +48,13 @@ func BatchDebounceEvents(ctx context.Context, clock clockwork.Clock, input <-cha | |
| seen = utils.Set[FileEvent]{} | ||
| } | ||
|
|
||
| t := clock.NewTicker(QuietPeriod) | ||
| t := time.NewTicker(QuietPeriod) | ||
| defer t.Stop() | ||
| for { | ||
| select { | ||
| case <-ctx.Done(): | ||
| return | ||
| case <-t.Chan(): | ||
| case <-t.C: | ||
| flushEvents() | ||
| case e, ok := <-input: | ||
| if !ok { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[medium] Second test batch asserts no sync occurred, but
handleWatchBatchWILL callsyncer.Sync()— leaving a goroutine permanently blockedThe second event batch sends both
/rebuildand/sync/changed:/rebuildmatches theWatchActionRebuildrule → triggerss.rebuild(...)/sync/changedmatches theWatchActionSyncrule → triggerssyncer.Sync(...)which blocks on the unbufferedsyncer.synced <- pathshandleWatchBatchprocesses both actions (rebuild first, then sync viasyncfilesiteration — they are independent maps). Sosyncer.Sync()is called, and the goroutine durably blocks onf.synced <- paths(a bubble-internal channel send).After
synctest.Wait()returns (because all other goroutines are durably blocked), theselect { default: }branch is taken — the pending send onsyncer.syncedis never read. The blocked goroutine leaks inside the bubble. Whensynctest.Testexits and waits for all goroutines to finish, the test panics with a deadlock/goroutine-leak message rather than a clear failure.The original clockwork-based test used
time.After(100ms)as the "no sync" timeout, which would also time out incorrectly in this scenario — but the old test's assertion was already wrong before this PR (the test comment says// TODO: there's not a great way to assert that the rebuild attempt happened). The migration to synctest surfaces this latent bug as a hard panic.Fix options:
syncer.syncedafter the rebuild batch, then assert the contents were not pure-sync (or just drain it):/sync/changed), making the "no sync" assertion valid./sync/changedevent (since it matches a sync rule even in a rebuild batch), updating the test intention.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@docker-agent I think this is a false positive.
handleWatchBatchonly reaches the sync actions if the rebuild succeeds:In this test the rebuild intentionally fails (
invalid service "test". Must specify either image or build), sosyncer.Sync()is never called for the/sync/changedevent in that batch.That also explains the existing assertion and TODO: the mixed batch is useful to verify that sync processing does not continue after the rebuild failure, while the test doesn't have a clean way to directly assert the rebuild attempt itself.
With
synctest.Wait()followed by the non-blocking select, the original assertion remains valid and deterministic.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're absolutely right — I misread the control flow. The early return on rebuild failure means
syncer.Sync()is never reached for the/sync/changedevent in the mixed batch, so the "no sync" assertion is correct.I've stored this pattern (early-return-on-rebuild-failure preventing downstream sync processing) to avoid flagging it incorrectly in future reviews. Thanks for the clarification and for explaining the test's intention — the mixed batch now makes much more sense as a deliberate verification that sync doesn't proceed after rebuild failures.