Is waitForReady required for retry policies?

[cha-king]

Hi there! I'm having a little bit of a hard time wrapping my head around the retry policies. One thing I've noticed is that all of the examples seem to set waitForReady to true in the method config. Is this required for retries to occur? Without setting this to true, all of my (expectedly broken) connection attempts seem to immediately fail otherwise.

Is the idea that, with waitForReady enabled, any configured retries are occurring internally while I wait for the RPC connection? And if I use waitForReady without a retry policy and an error occurs, must I wait for a timeout or explicit cancellation before I'd see that error?

Thanks!

[purnesh42H]

WaitForReady indicates whether RPCs sent to this method should wait until the connection is ready by default (!failfast). If waitForReady is false and the connection is in the TRANSIENT_FAILURE state, the RPC will fail immediately. Hence, you do need to set it true for retry. Please refer for more details here

[dfawley]

One thing I've noticed is that all of the examples seem to set waitForReady to true in the method config

We should change this, though. I'll send a PR.

[cha-king]

@dfawley Shouldn't the examples keep it if it is required for retry though?

Hence, you do need to set it true for retry.

[dfawley]

Sorry, I read that the other way around. It's not required for retry. The retry gRFC doesn't mention waitForReady at all:

https://github.com/grpc/proposal/blob/master/A6-client-retries.md

These are two different features and they affect RPC behavior in different ways.

"Wait for ready" allows your RPC to wait forever (up to the deadline you set in the context) during times when all addresses errored attempting to connect, before the RPC is sent on any connection. This is fairly rare to use, since that kind of condition usually would be persistent for longer than an average RPC would be willing to wait.

"Retry" will retry any RPC error that matches the status codes configured. Typically this is going to come from the backend server, but may also be UNAVAILABLE errors due to connection problems.

[cha-king]

Thanks for clarifying! At the moment, I'm mostly trying to get a better sense for what the expected retry behavior is through the API with "wait for ready" set to false.

For instance, if I'm attempting to call a streaming RPC and the server is unavailable, should I expect the RPC call to block as the retries are occurring? Even if "wait for ready" is disabled?

[dfawley]

IIUC, it should retry in this situation, with the configured backoff behavior between attempts. Note that the backoff delay is a random time between 0s and the exponential backoff interval, so in theory you may get several instantaneous attempts that all fail when this situation occurs. Generally, you probably wouldn't rely on gRPC retry to deal with major connectivity issues (i.e. all backends are unreachable).

[cha-king]

Thanks! I'll keep playing around with it.