You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is because ManagedChannelImpl's exitIdleMode() does not call channelStateManager.gotoState(CONNECTING);. When exiting idle mode, the next state transition is in LbHelperImpl.updateBalancingState(), which is after the NR has returned its initial results.
The name resolver takes some time before it returns addresses. While waiting the channel will be IDLE instead of the proper CONNECTING. This generally doesn't matter since RPCs behave similarly for IDLE and CONNECTING, but is confusing for users when watching channel.getState() closely.
Fixes#10517.
This is because ManagedChannelImpl's
exitIdleMode()
does not callchannelStateManager.gotoState(CONNECTING);
. When exiting idle mode, the next state transition is inLbHelperImpl.updateBalancingState()
, which is after the NR has returned its initial results.This generally doesn't matter much because RPCs behave similarly for IDLE and CONNECTING. But it would be confusing when using the
getState()
API, like the user at https://stackoverflow.com/questions/76950718/after-the-channel-is-created-it-takes-1000ms-to-transition-from-idel-state-to .The text was updated successfully, but these errors were encountered: