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.

Stabilize channel state API #4359

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions