Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In picker logic(picker_wrapper.go), clearly understand the real reason for failures after a context.Error(timeout) #7135

Closed
holdno opened this issue Apr 17, 2024 · 2 comments · Fixed by #7206
Assignees

Comments

@holdno
Copy link
Contributor

holdno commented Apr 17, 2024

if err == balancer.ErrNoSubConnAvailable {

Should we consider setting the error content for lastPickErr so that clients can clearly understand the real reason for failures after a timeout? This might improve troubleshooting and user experience.

if err == balancer.ErrNoSubConnAvailable {
    lastPickErr = err
    continue
}
@aranjans
Copy link
Contributor

Hi @holdno, can you please share your findings on running your code?

@holdno
Copy link
Contributor Author

holdno commented Apr 18, 2024

If the server-side balancer picks balancer.ErrNoSubConnAvailable, the gRPC picking logic will cause the context (ctx) to block until it times out. As a result, from the client's perspective, it appears as if there is a server response timeout, without knowing that it is due to NoSubConnAvailable.

What kind of code execution results do you need me to provide? Could you give an example or refer to another issue? Alternatively, I could submit the changes as a PR.
Thank you.

#7143

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants