Flaky TestServerListening in control due to unclosed servers and timing race
Metadata
Current evaluation
control.TestServerListening flakes in CI: hardcoded port 18111 reused by three tests, servers never Stop()ed, and a 500ms sleep instead of waiting on ctl2.Dying(). Proposed fix with root cause analysis.
Suggested action: needs triage
Reason: The report is unlabelled with zero comments, so no maintainer triage is recorded yet, but the body is a complete bug report: an exact failure output (ctl2.Err() == "tomb: still alive" vs expected "bind: address already in use"), a CI run link, root cause, and a three-part fix. I verified the cause against the code at HEAD — control/control_test.go uses hardcoded port 18111 in TestStartStop, TestServerError and TestServerListening, and only TestStartStop calls Stop(); TestServerError leaves ListenAndServe bound in a tomb goroutine, so TestServerListening's first ctl can fail to bind and the fixed time.Sleep(500ms) races the asynchronous ListenAndServe in control.go's Start(). Impact is limited to CI reliability (test-only change, no production code involved), hence moderate impact and low complexity.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
32
Quick Win:
23
Complexity:
18
Confidence:
86
Actionability:
86
|
needs triage | control.TestServerListening flakes in CI: hardcoded port 18111 reused by three tests, servers never Stop()ed, and a 500ms sleep instead of waiting on ctl2.Dying(). Proposed fix with root cause analysis. | |
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
29
Complexity:
28
Confidence:
85
Actionability:
88
|
keep open | controlSuite.TestServerListening flakes in CI: ctl/ctl2 are never stopped and port 18111 is hardcoded, plus a 500ms sleep races the async bind failure, so ctl2.Err() returns "tomb: still alive". Maintainer-authored with root cause and a concrete fix. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Related To:
fetch-service#661
(confidence 55%)
The failing Actions run linked in the body ends with ?pr=661, so the flake surfaced on that pull request; not verified as the source of the port conflict.
Related issues
No related issues found above the similarity threshold.