From f50156d99d3df40b96de174486b25a1681bd0f98 Mon Sep 17 00:00:00 2001
From: OdooSky v3 <m@havari.me>
Date: Tue, 5 May 2026 12:12:57 +0200
Subject: [PATCH] feat(traefik): tenants-default-retry Middleware (3 attempts,
 200ms init)

---
 templates/tenants-default-middlewares.yaml | 30 ++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 templates/tenants-default-middlewares.yaml

diff --git a/templates/tenants-default-middlewares.yaml b/templates/tenants-default-middlewares.yaml
new file mode 100644
index 0000000..8abf228
--- /dev/null
+++ b/templates/tenants-default-middlewares.yaml
@@ -0,0 +1,30 @@
+# Default Traefik Middlewares applied to every tenant IngressRoute.
+# Living at the cluster level (not in instance-template-v3) so the
+# policy is a one-place edit — every instance picks them up by name
+# from its own `tenants` namespace, no cross-namespace reference
+# trickery and no per-chart redeclare.
+#
+# tenants-default-retry — small retry budget so a transient 1-2s
+# Pod-not-ready window during an Odoo restart (addon install, Helm
+# rollout, etc.) doesn't surface as Traefik's "404 page not found"
+# to the customer. Traefik's retry only covers TCP-level failures
+# (connection refused / no available servers), not HTTP 5xx — so it
+# never re-sends a POST to a server that already accepted it.
+#
+# Tuning: 3 attempts with 200 ms initialInterval (doubled each
+# retry) → worst-case ~600 ms of latency before giving up. Within
+# typical browser patience and well below the 30 s+ window that a
+# slow Pod restart needs (we don't try to mask those — the user
+# eventually sees a clean 503 instead of a confusing 404).
+---
+apiVersion: traefik.io/v1alpha1
+kind: Middleware
+metadata:
+  name: tenants-default-retry
+  namespace: tenants
+  labels:
+    app.kubernetes.io/managed-by: cluster-platform-v3
+spec:
+  retry:
+    attempts: 3
+    initialInterval: 200ms