HTTPRoute overlap does not result in status conditions being set

[lyngekpdxc]

Description:
Envoy Gateway allows HTTPRoutes with overlapping exact paths to be applied with uncertain result.
I.e. what traffic is routed to which?

Gateway API documentation states that this should be well defined behaviour reported as status condition: https://gateway-api.sigs.k8s.io/guides/api-design/#conflicts

Repro steps:
Copy existing HTTPRoute definition. Change name. Deploy.
Now two HTTPRoutes will exist for the same exact path match, but with different backendservices.
Both are applied

Environment:
docker.io/envoyproxy/gateway-helm:v1.6.2
and
docker.io/envoyproxy/gateway-helm:v1.6.3

Logs:
I have included a sample HTTPRoute exhibiting this behaviour here

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: test-httproute
  namespace: service-namespace
spec:
  hostnames:
  - example.com
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: test-ingress
    namespace: test
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: myservice
      namespace: test
      port: 8080
      weight: 1
    matches:
    - path:
        type: Exact
        value: /testPath
status:
  parents:
  - conditions:
    - lastTransitionTime: "2026-01-28T15:04:55Z"
      message: Route is accepted
      observedGeneration: 3
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2026-01-28T15:04:55Z"
      message: Resolved all the Object references for the Route
      observedGeneration: 3
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    controllerName: gateway.envoyproxy.io/gatewayclass-controller
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: test-ingress
      namespace: test

[arkodg]

sure makes sense, there is a predetermined order for route match precedence, but we dont flag overlap, we can use this issue to add a ResolvedRefs:False with a Overlap like reason

[lyngekpdxc]

sure makes sense, there is a predetermined order for route match precedence, but we dont flag overlap, we can use this issue to add a ResolvedRefs:False with a Overlap like reason

Sounds like a good solution 👍
We are also making some counter measures ourselves, as we have the same problem in another component in our setup. We were just wondering why this didn't show in httproute as well. But perfect to add this with an overlap reason. As I think the current status is a bit misleading.

[Arpit529Srivastava]

hey @arkodg can i work in this?

[arkodg]

i can see @jukie already working on this, we should have updated labels, sorry about it, can you find another issue to work on

[Arpit529Srivastava]

No issues 😃, thanks