fix: chart 0.7.8 — raise KEDA interceptor cold-start timeouts (waitTimeout 180s, responseHeaderTimeout 30s)

Chart.yaml

@@ -23,8 +23,8 @@ description: |
       Git).
 
 type: application
-version: 0.7.7
+version: 0.7.8
-appVersion: "0.7.7"
+appVersion: "0.7.8"
 
 # All 6 subcharts now resolve from registry.odoosky.cloud (mirrored
 # 2026-05-08, KEDA stack added 2026-05-09). Mirror-first discipline

values.yaml

@@ -441,6 +441,26 @@ keda-add-ons-http:
       # handles bursts above that.
       min: 1
       max: 3
+      # waitTimeout (→ KEDA_CONDITION_WAIT_TIMEOUT) — how long the
+      # interceptor holds a request waiting for the target Deployment
+      # to scale 0→1 and become Ready. Upstream default is 20s; an AI
+      # Studio cold-start is image pull (~33s for the ~900 MB
+      # opencode-odoo image) + app boot (~30-60s) ≈ 60-90s, so 20s
+      # 502s the operator's first click ("context deadline exceeded
+      # while waiting for workload reach > 0 replicas"). 180s lets the
+      # first click WAIT through the cold-start instead of erroring;
+      # a warm pod is unaffected (this only caps the 0→1 wait).
+      # NOTE: the studio-template-v3 chart's per-HSO `spec.timeouts`
+      # block does NOT work — HTTPScaledObject CRD 0.8.0 has no such
+      # field; interceptor timeouts are GLOBAL, set here.
+      waitTimeout: "180s"
+    # responseHeaderTimeout (→ KEDA_RESPONSE_HEADER_TIMEOUT) — how
+    # long the interceptor waits for response headers after forwarding
+    # to a warm backend. Upstream default 500ms is far too tight for a
+    # just-woken Studio's first route load (OpenHands boots its
+    # browser env lazily); 30s is generous headroom without masking a
+    # genuinely hung backend.
+    responseHeaderTimeout: "30s"
     resources:
       requests:
         cpu: 50m