envoyproxy / envoyproxy/gateway

BackendTrafficPolicy timeout settings targeting Gateway are not applied to routes, but HTTPRoute-level timeouts work

Open
#9,513 1 comment 0 reactions 0 assignees View on GitHub
stale triage
Dominant language
Go
Stars
3k
Forks
864
Avg merge
2d 2h
Merged PRs (30d)
140

Description

When configuring HTTP timeouts via a BackendTrafficPolicy resource that targets a Gateway (using targetRefs with kind: Gateway), the timeout values are correctly reflected in the internal Envoy route configuration (visible in config dumps), but they are not effectively enforced. Requests still time out with 504 Gateway Timeout after the default 15 seconds.

However, when the same timeout configuration is applied directly at the HTTPRoute level (via annotation or per-route BackendTrafficPolicy targeting the specific HTTPRoute), the timeout is correctly enforced and requests are allowed to complete within the specified duration.

Expected behavior: A BackendTrafficPolicy targeting a Gateway should apply timeout settings to all routes attached to that Gateway, and those timeouts should be effectively enforced — not just present in the config dump.

Actual behavior: The timeout value appears in the Envoy route config ("timeout": "3600s") but is not enforced. Requests still fail with 504 after 15s. Only when the timeout is set directly on the HTTPRoute does it take effect.

Repro steps

1.- Deploy a Gateway with an HTTPRoute pointing to a backend that takes >15s to respond (e.g., ArgoCD server).

2.- Apply a BackendTrafficPolicy targeting the Gateway:

```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
name: backend-traffic-policy
namespace: envoy-gateway-system
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: eg
timeout:
http:
requestTimeout: "1h"
```

3.- Verify internal Envoy config shows the timeout is applied:

```yaml
"route": {
"cluster": "httproute/argocd/argocd-server-httproute/rule/0",
"timeout": "3600s",
"idle_timeout": "10000s"
}
```

4.- Make a request to the backend that takes >15s → Result: 504 Gateway Timeout

5.- Now apply a timeout directly on the HTTPRoute (e.g., via a BackendTrafficPolicy targeting the HTTPRoute, or using the timeouts field on the HTTPRoute):

```yaml
"route": {
"cluster": "httproute/argocd/argocd-server-httproute/rule/0",
"timeout": "900s",
"idle_timeout": "3600s"
}
```

6.- Make the same request → Result: Success, no 504

Environment
Envoy Gateway version: v1.8.0
Kubernetes version: (fill in)
Installation method: Helm chart (gateway-helm v1.8.0)
Gateway API version: (fill in, e.g. v1.2.x)
Logs
Access logs show 504 responses with response_flags: UT (Upstream Timeout) when the BackendTrafficPolicy is applied at the Gateway level, even though the config dump shows the correct timeout value.

(Attach sanitized Envoy access logs and config dump if possible)

Contributor guide

No contributing guide indexed for this repository

Research direction

Reproduce the Gateway-targeted BackendTrafficPolicy case from the listed steps, then compare the Envoy config dump and access logs with the HTTPRoute-targeted case. Focus on why the Gateway-level timeout is shown as 3600s but requests still receive 504 responses with response_flags UT. Done means Gateway-targeted timeouts are enforced consistently with HTTPRoute-level timeouts.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
backend-api-design, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.