fix: fix connection panic caused by WaitGroup misuse on close

[nodece]

Fixes #1483

Motivation

When closing a connection, failLeftRequestsWhenClose() waits on incomingRequestsWG before draining queued requests.

Previously, only SendRequest / SendRequestNoWait were tracked by the WaitGroup. WriteData could still enqueue into writeRequestsCh after close selection started, creating a race where buffered data requests were left undrained and never released.

Additionally, in Go 1.25+, calling Add(1) concurrently with Wait() on a WaitGroup can panic with sync: WaitGroup is reused before previous Wait has returned if close and in-flight request paths are not synchronized correctly.

Modifications

Introduced a shared registerIncomingRequest() helper used by all three entry points:

• SendRequest
• SendRequestNoWait
• WriteData

The registerIncomingRequest() helper performs:

1. c.mu.RLock()
2. state check (returns false if connectionClosed)
3. incomingRequestsWG.Add(1) (only if still open)

This ensures the check-and-add is atomic with respect to the close state transition:

• Close() sets state under c.mu.Lock(), creating a clear happens-before relationship
• After state becomes connectionClosed, no new request/write path can increment the WaitGroup
• Prevents concurrent Add() calls after Wait() has started, eliminating the panic

The non-blocking drain after Wait() is now safe and sufficient:

• All tracked producers have completed and called Done()
• All enqueues have completed before Wait() returns
• Drain releases leftover writeRequestsCh buffers and fails queued request callbacks

Testing

Added regression test TestConnectionSendRequestRaceWithClose that:

• Directly exercises the WaitGroup Add/Wait race by calling registerIncomingRequest() concurrently
• Calls failLeftRequestsWhenClose() to invoke Wait()
• Runs 10 trials with 50 concurrent goroutines to maximize race timing variations
• Verifies no panic occurs in Go 1.25+ with proper synchronization
• Confirms all three entry points properly reject requests after close via assertConnectionClosed

[Copilot]

Pull request overview

This PR addresses a connection-close race that can panic when SendRequest/SendRequestNoWait interact with WaitGroup while the connection is closing.

Changes:

• Synchronizes request state checks and WaitGroup.Add(1) with c.mu.RLock().
• Replaces sentinel-based channel draining with a non-blocking drain after waiting for in-flight requests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.