I am looking for examples of how to best use Istio / Envoy retries taking into account a services idempotent endpoints. The understanding being that retries for POST / DELETE verbs can be dangerous in cases where a connection was broken during a service call, but that service call may already be successfully completed or still ongoing. Without the idempotent endpoints and correct use of them, retries may cause problems.
I am thinking in terms of generation of idempotent ids for use in headers. Is there any concept in Istio / Envoy of a per call (plus that calls retries) idempotent id and map that to a header that the service might use.
If anyone has any details / examples of some idempotent endpoints + Istio / Envoy working nicely together it would be great, with the goal of minimizing the work that any calling service has to do (ideally it wouldn’t need to know about retries happening or idempotent ids being generated and used).
The recommendation from envoy is not to use automatic retries for non-idempotent transactions due to the nature of a distributed microservices based architecture. I quote the following sentence:
First, do not retry requests where retrying would change the result, such as non-idempotent transactions.
Thank you very much for that link. It has great details. In terms of adding a unique idempotent Id which many idempotent services would need as a header, is there any concept of the generation of this from istio or envoy to your knowledge. Or is the handling of these idempotent IDs completely down to the application itself to implement.