That was very helpful, thank you. My general conclusion is that basically I should not look at status codes, and instead decide:
a) My request can't be safely retried: I can assume the gRPC client MIGHT transparently retry in some cases, but otherwise its probably best to fail on any error. OR b) My request can be safely retried: In this case, I should probably just retry any error code, or do some request-specific inspection of the error. This avoids needing to know a lot about the subtle details of the gRPC implementation. :) Thanks again this was helpful, Evan On Monday, August 14, 2017 at 4:06:40 PM UTC-4, Abhishek Kumar wrote: > > The overall conclusion is correct that the client library will > transparently retry only in the case where there is a protocol level > guarantee that the server has not executed the RPC. However, this guarantee > may be available even for some RPCs that return INTERNAL error code and the > library is free to retry transparently in those cases. > > I would say that applications (service owners) should be free to decide if > UNIMPLEMENTED and UNAUTHENTICATED are also retriable. After all, auth > systems can have their own transient failures and new implementations can > be rolling out on the server side even as clients start using them. i.e., > there are corner cases where specific service owners may claim that for > their own services, these codes are retriable. That is why we allow service > owners full flexibility in selecting the status codes that can be retried. > (see: > https://github.com/grpc/proposal/blob/master/A6-client-retries.md#retryable-status-codes > > ) > > Hope this helps, > -ABhishek > > > On Friday, May 26, 2017 at 2:33:33 PM UTC-7, Evan Jones wrote: >> >> I've been looking into retry policies for my application, which meant >> I've spent some time reading the A6 client retries proposal [1], parts of >> the previous discussion thread [2], and the status code description [3]. >> Are there any of these status codes that are always safe to retry? In the >> terminology from A6, I'm trying to determine which requests have never >> possibly been seen by the server application logic (see transparent >> retries: [1]). >> >> In particular: It wasn't clear from me in A6 how the client will >> determine if a "transparent retry" is safe. Will it use status codes? >> Something else? >> >> >> It seems to me that according to the Status Codes document [3] the only >> code that should be safe to always retry, since the server application >> logic could never have executed, is UNAVAILABLE. >> >> >> As for the opposite case, you should never retry UNIMPLEMENTED, >> UNAUTHENTICATED because they should be "permanent" errors that won't >> succeed when re-executed. >> >> >> The rest are application dependent, since the request could have executed >> (partially or completely). >> >> Did I get this right? >> >> Thanks! >> >> Evan >> >> >> [1] >> https://github.com/grpc/proposal/blob/master/A6-client-retries.md#transparent-retries >> [2] https://groups.google.com/forum/#!topic/grpc-io/zzHIICbwTZE >> [3] https://github.com/grpc/grpc/blob/master/doc/statuscodes.md >> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/dd6b53a6-bf0e-497c-8612-035e178a2e7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
