Stabilize channel state API

[ejona86]

ManagedChannel.getState(), ManagedChannel.notifyWhenStateChanged(), and ConnectivityState.

[chbatey]

Would it be possible to extend this API to observe every state change? E.g. rather than a one off callback a consumer that receives the previous and new state for each state change?

[ejona86]

Not really. It was an explicit design goal to avoid showing every state change. Basically, state changes can happen very rapidly and that would cause them to queue up, depending on the processing speed of the application.

@chbatey, what is your use-case for seeing every transition?

[abekenza]

Not sure if I am writing in correct thread, but in my use case users should be able to see current connection state like: connecting and connected

[ejona86]

@abekenza, yes, this is the correct API. You can use ManagedChannel.getState() and notifyWhenStateChanged()

[ptravers]

👋 I am planning to use this API in a production setting so was curious as to what work is left to stabilise this API?

[ejona86]

There are no plans to change the methods and enum list. However, the specific meaning/transitions between states is a little in flux. In particular, after TRANSIENT_FAILURE we go back to IDLE (and then later CONNECTING) after a backoff period. However, that causes "lurches" of extremely poor RPC latency when things are broken, for little benefit, because we queue RPCs for IDLE/CONNECTING and broken networks can take a long time for connection attempts to fail. It is described in part in #6650 . But essentially, I want to make a similar change to pick_first where things stay in TRANSIENT_FAILURE until proven to be healthy again (at which point we've clearly minorly redefined the meaning of the enum states). But there's difficulty with pick_first that needs to be discussed cross-language.

I don't expect any changes to break users of this API using it for health/status notification. But if someone is using the API and changing their RPC behavior because of what it returns (e.g., not sending RPCs if the Channel is TRANSIENT_FAILURE), then there could be surprises (it should be fine, but technically it is a behavior/API change and I really don't want to argue with people if it causes minor problems). I also wouldn't be surprised if some users were using the API to reverse engineer our exponential backoff state, and that would definitely break.

[larry-safran]

The 2 methods are okay, but for ConnectivityState we recently changed the behavior with pickFirst sticky TF state and some of the descriptions are not true.
Shouldn't talk about transitions in the state descriptions.

Prereq cross language definition of states