Repository navigation
test: run gitbranch watcher stress test in-memory with synctest - #4616
Merged
Merged
Conversation
Drops disk I/O and the 10s timeout fallback in favor of synctest, removing the flakiness under load. Assisted-By: docker-agent
trungutt
approved these changes
Oct 16, 2026
melmennaoui
approved these changes
Oct 16, 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.
Why
Windows CI job 116939219866 (run 38890691710) failed because
pkg/gitbranch/watcher_test.go's stress test exceeded its 10s wall-clock deadline — the test does 10,000 disk-backed refreshes, which is too slow under Windows CI load.What
Current("")call, run insidetesting/synctest.No production code is changed — test-only.
Validation
task build,task test,task lint-count=1000 -cpu=1,2,4,8)Reviewer also reran the whole
gitbranchpackage under-race, and confirmed via mutation testing that reintroducing the original blocking drain triggers asynctestdeadlock (i.e. the test still catches the original bug). Native Windows execution was not performed locally.