grpc: protect field access with lock to avoid potential data race

[yanke-xu]

It seems to be a potential data race. Specifically, there are two confilicting operations on the field "Addresses", where the read operation is protected by a lock at: grpc/pickfirst.go:90, and the write operation is unprotectd by the lock at:grpc/resolver_conn_wrapper.go:126. A data race may occurs when the two functions where the two operations are located.

[dfawley]

We need more information to proceed, here.

1. What version of the code are you looking at? master@HEAD doesn't have any relevant code on those lines.
2. How did you discover the problem? Is this code inspection and speculation?
3. Do you have a proposed fix?

[github-actions[bot]]

This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[yanke-xu]

1. may be the v1.50.0;
2. code analysis;
3. adding a lock to the unprotected operation.

[dfawley]

I don't see any issue here. If you can be much more specific, and ideally reference master@HEAD or something more recent, then we could investigate further.