kube: handle goaway test fixture conns concurrently#66934
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 795722f11b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| g.mu.Unlock() | ||
| g.wg.Wait() |
There was a problem hiding this comment.
Prevent Close from returning before accepted conn handlers start
A connection accepted just before Close() takes g.mu can be appended and launched after the close loop unlocks, because Serve() does append+wg.Go under the same mutex but Close() releases the mutex before wg.Wait(). In that interleaving, Close() can miss closing that conn and return without waiting for its handler, leaving a goroutine blocked in TLS/frame reads and reintroducing teardown flakiness under concurrent tests.
Useful? React with 👍 / 👎.
Follow-up to #66672. The fake
goawayServerinforwarder_test.gocallshandleConninline, so concurrent clients inTestGOAWAYHandling_Concurrentare serialized. Under-race+ slow CI, the 50-deep backlog can outlast the per-request 10s context, leaving thehttptesthandler stuck in TLS handshake andforwarderServer.Close()waiting on it until Go's 10-minute test timeout fires.Example: https://github.com/gravitational/teleport/actions/runs/26193145084/job/77066278419?pr=66930
Fix: spawn a goroutine per accepted conn. No production code touched.
Stress:
stress -p 8 -test.cpu=1 -racefor ~4 min — 1,317 runs, 0 failures.