skip invalid listener first in IR#8577
Conversation
✅ Deploy Preview for cerulean-figolla-1f9435 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8577 +/- ##
==========================================
- Coverage 74.69% 74.67% -0.02%
==========================================
Files 251 251
Lines 40257 40398 +141
==========================================
+ Hits 30068 30166 +98
- Misses 8123 8160 +37
- Partials 2066 2072 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
45bd0eb to
e9a458a
Compare
f5bee1d to
2db4164
Compare
| message: Route is accepted | ||
| reason: Accepted | ||
| status: "True" | ||
| message: Multiple routes on the same TCP listener |
There was a problem hiding this comment.
this's because tcp-80 is invalid and skipped now.
2db4164 to
1fa2c97
Compare
1fa2c97 to
46b11c4
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
gateway/internal/gatewayapi/validate.go
Lines 659 to 660 in 46b11c4
validateListenerSpec now depends on validateTLSConfiguration’s boolean to decide whether a listener should be excluded from conflict resolution, but the frontendTLSValidation.ValidateError path only sets conditions and never flips specValid to false. That means listeners with invalid frontend CA refs can still participate in conflict checks and block otherwise valid listeners on the same port/hostname, which defeats the intended invalid-first skip behavior in this change.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
f587c83 to
97a571f
Compare
7f0e72b to
b214810
Compare
|
possible not
|
| name: http-80 | ||
| protocol: HTTP | ||
| servicePort: 80 | ||
| - name: envoy-gateway/gateway-2/https |
There was a problem hiding this comment.
why is existing logic for Gateway listeners changing ?
There was a problem hiding this comment.
- attachedRoutes: 1
conditions:
- lastTransitionTime: null
message: Listener must have TLS set when protocol is HTTPS.
reason: Invalid
status: "False"
type: Programmed
- lastTransitionTime: null
message: Listener references have been resolved
reason: ResolvedRefs
status: "True"
type: ResolvedRefs
name: https
supportedKinds:
- group: gateway.networking.k8s.io
kind: HTTPRoute
- group: gateway.networking.k8s.io
kind: GRPCRoute
Signed-off-by: zirain <zirain2009@gmail.com>
Signed-off-by: zirain <zirain2009@gmail.com>
Signed-off-by: zirain <zirain2009@gmail.com>
89a7c66 to
b77d5dc
Compare
rudrakhp
left a comment
There was a problem hiding this comment.
A few questions on the new listener validation flow.
| seenUDPProtocol := false | ||
| for _, listener := range listenersOnPort { | ||
| protocol := getProtocolForListener(listener) | ||
| if protocol == string(gwapiv1.UDPProtocolType) { |
There was a problem hiding this comment.
The multi-UDP conflict branch looks unreachable in practice (gated by len(nonUDPProtocols) > 1 earlier), and validateConflictedLayer4Listeners(UDP) already flags the same condition. Can we drop UDP handling from this function and let validateConflictedLayer4Listeners own UDP port conflicts?
| // conflict detection. In the normal translation flow this is driven by | ||
| // listener.specValid. The fallback keeps direct unit tests meaningful when they | ||
| // invoke conflict checks without running per-listener spec validation first. | ||
| func isSpecValidForConflictChecks(listener *ListenerContext) bool { |
There was a problem hiding this comment.
isSpecValidForConflictChecks falls back to hasInvalidCondition so unit tests that skip Phase 1 keep working. Doesn't this mean real-flow regressions in Phase 1 to Phase 2 ordering would be masked by the fallback? Could we update direct-call tests to run validateListenerSpec first and then rely solely on listener.specValid? If the fallback stays, can we add a comment noting it exists only for tests that skip Phase 1?
updated |
|
LGTM, thanks! |
This's seperated from #8361
Invalid listeners should probably be skipped before check confilict.
Otherwise an invalid-first listener can still win hostname/protocol precedence and cause a later valid listener on the same hostname/port to be marked HostnameConflict.