Setting the retry policies, if empty param is given will not generate any headers but using the default setting in Envoy's config
the params for initialize the request params
request context read from ingress traffic
extra customer headers to be set in the request
If a retry policy is in place, Envoy will default to retrying one time unless explicitly specified. The number of retries can be explicitly set in the route retry config or by using this header. If a retry policy is not configured and x-envoy-retry-on or x-envoy-retry-grpc-on headers are not specified, Envoy will not retry a failed request.
A few notes on how Envoy does retries:
The route timeout (set via x-envoy-upstream-rq-timeout-ms or the route configuration) includes all retries. Thus if the request timeout is set to 3s, and the first request attempt takes 2.7s, the retry (including backoff) has .3s to complete. This is by design to avoid an exponential retry/timeout explosion.
Envoy uses a fully jittered exponential backoff algorithm for retries with a base time of 25ms. The first retry will be delayed randomly between 0-24ms, the 2nd between 0-74ms, the 3rd between 0-174ms and so on.
If max retries is set both by header as well as in the route configuration, the maximum value is taken when determining the max retries to use for the request.
Setting this will cause Envoy to set a per try timeout on routed requests. This timeout must
be <= the global route timeout (see
on what condition shall envoy retry
Setting this header on egress requests will cause Envoy to override the route configuration.
The timeout must be specified in millisecond units.
Also see
assemble the request headers for setting retry. TODO: in direct mode, we may need to modify the tracing headers
Generated using TypeDoc
the HTTP request params, mainly two parts: