Retry is an outbound policy. Dataplanes whose configuration is modified are in the
This policy enables Kong Mesh to know how to behave if there is a failed scenario (i.e. HTTP request) which could be retried.
As usual, we can apply
destinations selectors to determine how retries will be performed across our data plane proxies.
The policy let you configure retry behaviour for
Amount of attempts which will be made on failed (and retriable) requests
Amount of time after which retry attempt should timeout (i.e. all the values:
0.0005m are equivalent and can be used to express the same timeout value, equal to
Configuration of durations which will be used in exponential backoff strategy between retries
Base amount of time which should be taken between retries (i.e.
A maximal amount of time which will be taken between retries (i.e.
A list of status codes which will cause the request to be retried. When this field will be provided it will overwrite the default behaviour of accepting as retriable codes:
504 and if they also should be considered as
retriable you have to manually place them in the list
For example to add a status code
retriableStatusCodes is provided in addition to
retryOn (below), but the latter doesn’t contain
retriable_status_codes as a condition, it will be automatically added.
List of conditions which will cause a retry.
A list of HTTP methods in which a request’s method must be contained before that request can be retried. The default behavior is that all methods are retriable.
You can configure your GRPC Retry policy in similar fashion as the HTTP one with the only difference of the
retryOn property which replace the
retriableStatusCodes from the HTTP policy
Retry is an Outbound Connection Policy.
The only supported value for
Builtin Gateway support
Retries can be configured on each route by matching the
Retry connection policy to the backend destination tags.