SAY-5 opened a new pull request, #1489:
URL: https://github.com/apache/pulsar-client-go/pull/1489
Fixes #1483.
### Motivation
`failLeftRequestsWhenClose` calls `c.incomingRequestsWG.Wait()` to drain
in-flight `SendRequest` / `SendRequestNoWait` callers, but those callers do
`incomingRequestsWG.Add(1)` *before* checking `c.getState() ==
connectionClosed`. A caller that started concurrently with the close path can
therefore execute `Add(1)` at the exact moment `Wait()` is finishing draining
to zero, which Go treats as a reuse violation:
```
panic: sync: WaitGroup is reused before previous Wait has returned
goroutine ...
sync.(*WaitGroup).Wait(...)
github.com/apache/pulsar-client-go/pulsar/internal.(*connection).failLeftRequestsWhenClose(...)
github.com/apache/pulsar-client-go/pulsar/internal.(*connection).run(...)
```
This is the production crash captured in #1483.
### Modifications
Add a `sync.RWMutex` (`incomingRequestsLock`) that gates the `Add(1)` so it
cannot interleave with `Wait()`:
* `SendRequest` / `SendRequestNoWait` take **RLock**, check state, `Add(1)`,
**RUnlock**. Multiple senders still proceed in parallel.
* `failLeftRequestsWhenClose` takes **Lock**, sets state=closed,
**Unlocks**, then `Wait()`. The exclusive section guarantees:
1. no in-flight `Add(1)` straddles the `Wait()`, and
2. any caller arriving after this point sees `state == connectionClosed`
and returns `ErrConnectionClosed` without touching the WaitGroup.
Inline comments in both call sites document why the lock is necessary so
future contributors don't re-introduce the race.
### Verifying this change
- [x] `go build ./pulsar/internal/...` passes
- [x] `go vet ./pulsar/internal/...` passes
- [x] `go test -count=1 -short ./pulsar/internal/` — all internal tests
still pass
### Documentation
- [x] `doc-not-needed` (bug fix in internal package; no public API change)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
