Aias00 opened a new pull request, #3442: URL: https://github.com/apache/dubbo-go/pull/3442
## Problem `serviceListeners` map in `serviceDiscoveryRegistry` was read/written without holding the lock, while the same struct's `serviceMappingListeners` already had proper lock protection via `s.lock`. This could cause data races when concurrent subscribe/unsubscribe operations access the map. ### Unprotected access locations - `SubscribeURL` (line 365): read `s.serviceListeners[serviceNamesKey]` — no lock - `SubscribeURL` (line 381): write `s.serviceListeners[serviceNamesKey] = listener` — no lock - `UnSubscribe` (line 203): read `s.serviceListeners[serviceNamesKey]` — no lock ### Contrast with protected `serviceMappingListeners` - `findMappedServices`: `s.lock.Lock()` / `s.lock.Unlock()` - `stopListen`: `s.lock.Lock()` / `s.lock.Unlock()` ## Fix - **`SubscribeURL`**: Use `s.lock.Lock()` / `s.lock.Unlock()` to protect the check-then-act read+write of `serviceListeners`. A write lock is required (not RLock) because the method follows a check-then-act pattern — it first reads to check if a listener exists, then conditionally creates and writes one. Using RLock would allow concurrent reads but not prevent the TOCTOU race. - **`UnSubscribe`**: Use `s.lock.RLock()` / `s.lock.RUnlock()` for the read-only access of `serviceListeners`, consistent with read-lock usage elsewhere in the codebase. ## Testing - `go build ./registry/servicediscovery/...` ✅ - `go vet ./registry/servicediscovery/...` ✅ - `go test ./registry/servicediscovery/... -count=1` ✅ -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
