Set a channel's idle timeout

[joshuakarp]

Is your feature request related to a problem? Please describe.

A gRPC channel has observable connection states: CONNECTING, READY, TRANSIENT_FAILURE, IDLE, and SHUTDOWN (as per https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html). Specifically, the channel's transition from READY to IDLE is governed by the "idle timeout" value of the channel. There's a couple of pieces of documentation from gRPC core that talk about this idle timeout parameter:

• https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html stating the default value is 5 minutes
• https://grpc.github.io/grpc/core/group__grpc__arg__keys.html#ga51ab062269cd81298f5adb6fd9a45e99 stating the default value is 30 minutes

We use these low-level transitions to perform specific logic on our domain's connections, and would like to test this specific transition from READY to IDLE (but don't want a test that runs for 5 or 30 minutes).

Describe the solution you'd like

We'd like a publicly-exposed means of adjusting the value of the channel's idle timeout (e.g. a ChannelOptions parameter when initialising the channel).

Describe alternatives you've considered

We've taken a look in the ClientOptions and ChannelOptions in grpc-js, but have had no luck in finding anything that would resolve this problem.

Although, there are the options of keepalive_time_ms and keepalive_timeout_ms. Would it be possible to use these to augment this functionality? Or any other further options that might be useful here?

Additional context

• discussion post here https://groups.google.com/g/grpc-io/c/yq4pmBGaXOQ
• relevant domain-specific issue for our usecase Verify GRPC channel connectivity state READY to IDLE transition MatrixAI/Polykey#332

[murgatroid99]

Just to clarify, when I said "grpc-js does not currently support that functionality", I meant that grpc-js does not implement the idle timeout functionality at all. Currently, the only way for a channel to transition from READY to IDLE is if the connection drops.

[murgatroid99]

In addition, regarding this:

We use these low-level transitions to perform specific logic on our domain's connections

I would recommend not doing that, if possible. The channel state is primarily informational, and the gRPC API is intended to be used without ever checking the channel state. In particular, related to what I see in your linked issue, gRPC itself does not consider IDLE to be a terminal state; a gRPC channel can generally transparently reconnect after going IDLE. There may be a simpler way of doing what you are trying to accomplish without relying on channel state changes.

In addition, related to some discourse I see in your issue, this IDLE timeout, if it was implemented, would be focused on application-level events. It is not related to TCP-level activity or connectivity, but rather about how long since there have been any active gRPC-level requests. The detection of TCP connection loss is handled separately.

The keepalive parameters you mention control HTTP/2 pings that are sent to prevent servers and proxies from closing connections due to inactivity. By default they are only sent if a connection has had at least one open stream continuously for the specified amount of time, because their primary purpose is to keep connections open while they host long-running streams that may be intermittently idle. The channel option 'grpc.keepalive_permit_without_calls' changes that so that pings are always sent at the specified interval whether or not there are any open requests. These pings can also be used to catch when connections drop: if the server does not respond to the ping within the configured timeout, the connection is dropped.

[murgatroid99]

The channel IDLE timeout has been implemented in grpc-js 1.9.x. It defaults to 30 minutes and is controlled by the grpc.client_idle_timeout_ms channel option.