-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
grpclb: Don't go into fallback if we haven't started picking #13339
Conversation
|
|
Would be nice to see a test for this. It should be easy to trigger -- just send a resolver update before the fallback timer fires. |
|
Triggering the pre-existing failure not that easy. As I previously described, we'd need the ability to send resolver updates after the policy creation but before a pick. We could do this in a crude manner by flooding the policy with updates sent from a separate thread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I see your point -- I was somehow mentally confusing the fallback timer firing and the LB policy starting picking.
In principle, it should probably be possible to test this by letting the channel go into IDLE state and then sending a resolver update. But we don't currently reset started_picking
when we go into IDLE (although we probably should; I've added a note about this to our client channel roadmap doc), so there's no way to do this right now.
See #13306 for previous discussion.
Fixes #13333