Multiple retry policies
kevmo314 opened this issue · 9 comments
Hi, how can I support multiple retry policies? I'd like to handle different status codes accordingly but the library seems to only support one retry policy if I'm reading it correctly.
Can you give me an example of your use case?
One way is to create separate GRPCExecutors. A GRPCExecutor will use whichever client that you provide when you make your call, which means that you will not be opening multiple connections to your server if you use the same client.
I periodically see error codes 14 and 8 on long-running bidirectional streams, corresponding to unavailable and resource exhausted: https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
I want to retry immediately for unavailable (server may have switched or connection break) but add a timer for resource exhausted.
Have you considered implementing retry with exponential backoff? That would allow you to retry initially with a very short delay, but increase that delay quickly in order to not flood a backend that is under heavy load.
What's a good way to implement that? I'd like it so it isn't just a function of retry count because I see that I get a "14 unavailable" once an hour on my RPC, so the retry count will keep going up. I thought of wiring a backoff/throttling subject in the middle but it's quite messy.
I think that it makes more sense to reset the retry count if the call succeeds, rather than letting it go up indefinitely.
We can also provide delayUntilNext with the RPCError. I.e. change its signature to (Int, RPCError) -> AnyPublisher<Void, Never>. Unfortunately this one will be a breaking API change.
How do these changes look w.r.t. your use case?
That would work for me!
I have implemented the above. Can you check out the current master branch and let me know if that works for you?
Change looks good to me! Thanks!