zeekayandHanzo Dev
15d100931d
Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
2.4 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress HTTP Retry Documentation | Configure Hanzo Ingress's HTTP Retry middleware, so you can retry requests to a backend server until it succeeds. Read the technical documentation. |
Retry
Retrying until it Succeeds {: .subtitle }
The Retry middleware reissues requests a given number of times when it cannot contact the backend service. This applies at the transport level (TCP). If the service does not respond to the initial connection attempt, the middleware retries. However, once the service responds, regardless of the HTTP status code, the middleware considers it operational and stops retrying. This means that the retry mechanism does not handle HTTP errors; it only retries when there is no response at the TCP level. The Retry middleware has an optional configuration to enable an exponential backoff.
Configuration Examples
# Retry 4 times with exponential backoff
labels:
- "ingress.http.middlewares.test-retry.retry.attempts=4"
- "ingress.http.middlewares.test-retry.retry.initialinterval=100ms"
# Retry 4 times with exponential backoff
apiVersion: hanzo.ai/v1alpha1
kind: Middleware
metadata:
name: test-retry
spec:
retry:
attempts: 4
initialInterval: 100ms
# Retry 4 times with exponential backoff
- "ingress.http.middlewares.test-retry.retry.attempts=4"
- "ingress.http.middlewares.test-retry.retry.initialinterval=100ms"
# Retry 4 times with exponential backoff
http:
middlewares:
test-retry:
retry:
attempts: 4
initialInterval: 100ms
# Retry 4 times with exponential backoff
[http.middlewares]
[http.middlewares.test-retry.retry]
attempts = 4
initialInterval = "100ms"
Configuration Options
attempts
mandatory
The attempts option defines how many times the request should be retried.
initialInterval
The initialInterval option defines the first wait time in the exponential backoff series. The maximum interval is
calculated as twice the initialInterval. If unspecified, requests will be retried immediately.
The value of initialInterval should be provided in seconds or as a valid duration format, see time.ParseDuration.