Description:
Upgraded from v1.7.2 to v1.8.0. The gateway-api runner now panics every reconcile.
Because the translator can't finish, the controller never pushes the new image to the data plane. Our data plane Pods are still on v1.7.2.
Looks like a nil check was dropped during a refactor. The receiver gtwCtx is dereferenced without checking if it's nil:
https://github.com/envoyproxy/gateway/blob/v1.8.0/internal/gatewayapi/backendtlspolicy.go#L145
The caller passes gatewayCtx straight through, even though a few lines above it already checks if gatewayCtx != nil:
https://github.com/envoyproxy/gateway/blob/v1.8.0/internal/gatewayapi/route.go#L1880-L1913
For comparison, v1.7.2 used to guard this call:
https://github.com/envoyproxy/gateway/blob/v1.7.2/internal/gatewayapi/backendtlspolicy.go#L140
Repro steps:
Have some HTTPRoutes with BackendTLSPolicy attached, then upgrade from v1.7.2 to v1.8.0. We have ~22 BackendTLSPolicy resources in the cluster.
I can't pin down which specific route hits the nil gatewayCtx — the panic just fires on every translate.
Environment:
- Envoy Gateway v1.8.0
- Kubernetes v1.36.0
- Gateway API CRDs v1.5.1
Logs:
error gateway-api message/watchutil.go:65 observed a panic
{"runner": "gateway-api", "error": "runtime error: invalid memory address or nil pointer dereference"}
goroutine 227 [running]:
runtime/debug.Stack()
github.com/envoyproxy/gateway/internal/message.handleWithCrashRecovery[...].func1()
internal/message/watchutil.go:66 +0xda
panic({0x340a240?, 0xb59a330?})
github.com/envoyproxy/gateway/internal/gatewayapi.(*GatewayContext).GetBackendTLSConfig(...)
internal/gatewayapi/contexts.go:53
github.com/envoyproxy/gateway/internal/gatewayapi.(*Translator).applyBackendTLSSetting(...)
internal/gatewayapi/backendtlspolicy.go:145 +0x46e
github.com/envoyproxy/gateway/internal/gatewayapi.(*Translator).processDestination(...)
internal/gatewayapi/route.go:1900 +0x815
github.com/envoyproxy/gateway/internal/gatewayapi.(*Translator).processHTTPRouteRules(...)
internal/gatewayapi/route.go:281 +0x878
github.com/envoyproxy/gateway/internal/gatewayapi.(*Translator).processHTTPRouteParentRefs(...)
internal/gatewayapi/route.go:118 +0xc5
github.com/envoyproxy/gateway/internal/gatewayapi.(*Translator).ProcessHTTPRoutes(...)
internal/gatewayapi/route.go:79 +0x225
github.com/envoyproxy/gateway/internal/gatewayapi.(*Translator).Translate(...)
internal/gatewayapi/translator.go:297 +0x73e
Description:
Upgraded from v1.7.2 to v1.8.0. The
gateway-apirunner now panics every reconcile.Because the translator can't finish, the controller never pushes the new image to the data plane. Our data plane Pods are still on v1.7.2.
Looks like a nil check was dropped during a refactor. The receiver
gtwCtxis dereferenced without checking if it's nil:https://github.com/envoyproxy/gateway/blob/v1.8.0/internal/gatewayapi/backendtlspolicy.go#L145
The caller passes
gatewayCtxstraight through, even though a few lines above it already checksif gatewayCtx != nil:https://github.com/envoyproxy/gateway/blob/v1.8.0/internal/gatewayapi/route.go#L1880-L1913
For comparison, v1.7.2 used to guard this call:
https://github.com/envoyproxy/gateway/blob/v1.7.2/internal/gatewayapi/backendtlspolicy.go#L140
Repro steps:
Have some HTTPRoutes with
BackendTLSPolicyattached, then upgrade from v1.7.2 to v1.8.0. We have ~22BackendTLSPolicyresources in the cluster.I can't pin down which specific route hits the nil
gatewayCtx— the panic just fires on every translate.Environment:
Logs: