You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add three user-facing timeouts configurable via InterceptorRoute CRD:
request (disabled by default), responseHeader (300s default), and
readiness (disabled by default, 30s when fallback is configured).
Timeout errors now return 504 Gateway Timeout instead of 502 Bad
Gateway.
Changes:
- Add timeouts spec to InterceptorRoute CRD and update CRD manifest
- Refactor timeout config to derive internal timeouts from three user-facing ones
- Propagate per-route timeouts through routing table and middleware
- Simplify dial context to single-arg DialContextWithRetry
- Cap dial retries at 1 minute when request timeout is disabled
- Fix fallback not being reached when readiness timeout >= request timeout
- Default readiness timeout to 30s when a fallback service is configured
- Remove legacy per-transport env vars (breaking), deprecate old naming
- Add unit tests for timeout config, routing, and upstream handler
- Expand e2e timeout tests for the new per-route behavior
- Delete unused pkg/k8s/annotations.go
Signed-off-by: Vincent Link <[email protected]>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,14 @@ This changelog keeps track of work items that have been completed and are ready
27
27
28
28
### Breaking Changes
29
29
30
+
-**Interceptor**: Change default timeout behavior: request timeout (`KEDA_HTTP_REQUEST_TIMEOUT`) defaults to `0` (disabled), response header timeout (`KEDA_RESPONSE_HEADER_TIMEOUT` → `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT`) defaults to `300s` (was `500ms`), and readiness timeout (`KEDA_CONDITION_WAIT_TIMEOUT` → `KEDA_HTTP_READINESS_TIMEOUT`) defaults to `0` (disabled, was `20s`). Timeout errors return 504 instead of 502. ([#1474](https://github.com/kedacore/http-add-on/issues/1474))
30
31
-**Interceptor**: Redesign interceptor metrics: `interceptor_request_count` → `interceptor_requests_total` (labels: `method`, `code`, `route_name`, `route_namespace`), `interceptor_pending_request_count` → `interceptor_pending_requests` (labels: `route_name`, `route_namespace`), added `interceptor_request_duration_seconds` histogram; `path` and `host` labels removed in favor of route identity via InterceptorRoute name/namespace to fix unbounded cardinality OOM issues; non-standard HTTP methods normalized to `_OTHER`; dashboards and alerting rules must be updated ([#1559](https://github.com/kedacore/http-add-on/issues/1559))
32
+
-**Interceptor**: Remove `KEDA_HTTP_TLS_HANDSHAKE_TIMEOUT`, `KEDA_HTTP_EXPECT_CONTINUE_TIMEOUT`, `KEDA_HTTP_KEEP_ALIVE`, `KEDA_HTTP_IDLE_CONN_TIMEOUT`, and `KEDA_HTTP_DIAL_RETRY_TIMEOUT` environment variables; these now use Go's `DefaultTransport` defaults. ([#1474](https://github.com/kedacore/http-add-on/issues/1474))
31
33
32
34
### New
33
35
34
36
-**General**: Add `InterceptorRoute` CRD to separate routing/interceptor config from scaling config; `HTTPScaledObject` remains supported but will be deprecated in a future release ([#1501](https://github.com/kedacore/http-add-on/issues/1501))
37
+
-**Interceptor**: Add per-route timeout configuration via InterceptorRoute `timeouts` spec with `request`, `responseHeader`, and `readiness` fields. When unset, global env var defaults are used. When a fallback service is configured and no readiness timeout is set, it defaults to 30s. ([#1474](https://github.com/kedacore/http-add-on/issues/1474))
35
38
36
39
### Improvements
37
40
@@ -43,7 +46,7 @@ This changelog keeps track of work items that have been completed and are ready
43
46
44
47
### Deprecations
45
48
46
-
-**General**: TODO ([#TODO](https://github.com/kedacore/http-add-on/issues/TODO))
49
+
-**Interceptor**: Deprecate `KEDA_CONDITION_WAIT_TIMEOUT` and `KEDA_RESPONSE_HEADER_TIMEOUT` environment variables in favor of `KEDA_HTTP_READINESS_TIMEOUT` and `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT`. Old vars take precedence when set and log deprecation warnings. ([#1474](https://github.com/kedacore/http-add-on/issues/1474))
Copy file name to clipboardExpand all lines: docs/integrations.md
+7-14Lines changed: 7 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,20 +40,13 @@ spec:
40
40
41
41
1. **Error: `context marked done while waiting for workload reach > 0 replicas`**
42
42
43
-
- This error indicates that the `KEDA_CONDITION_WAIT_TIMEOUT` value (default: 20 seconds) might be too low. The workload scaling process may not be complete within this timeframe.
44
-
- To increase the timeout:
45
-
- If using Helm, adjust the `interceptor.replicas.waitTimeout` parameter (see reference below).
- You might encounter 502 errors during POST requests when the request is routed through the interceptor service. This could be due to insufficient timeout settings.
51
-
- To adjust timeout parameters:
52
-
- If using Helm, modify the following parameters (see reference below):
- This error indicates that the readiness timeout might be too low. By default the readiness timeout is disabled (bounded only by the `request` timeout); when a fallback service is configured and no readiness timeout is set, it defaults to 30s.
44
+
- Set the `readiness` timeout in the InterceptorRoute `timeouts` spec or `KEDA_HTTP_READINESS_TIMEOUT` to a value that gives the workload enough time to scale up.
45
+
46
+
2. **502/504 Errors with POST Requests:**
47
+
48
+
- You might encounter timeout errors during POST requests when the request is routed through the interceptor service. This could be due to insufficient timeout settings.
49
+
- Increase `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` or set the `responseHeader` timeout in the InterceptorRoute `timeouts` spec.
57
50
58
51
3. **Immediate Scaling Down to Zero:**
59
52
- If `minReplica` is set to 0 in the HTTPScaledObject, the application will immediately scale down to 0.
0 commit comments