fix: prevent skeleton route status entries for unmanaged GatewayClasses

[rajsinghtech]

Description

Fixes a bug where HTTPRoutes referencing gateways with multiple different GatewayClasses would have incomplete status conditions.

Problem

When an HTTPRoute references gateways using different GatewayClasses (e.g., private, public, home-ts), the status showed all parentRefs with controllerName set, but only some had actual conditions (Accepted, ResolvedRefs). Others had just the controllerName field with no conditions array.

Example:

spec:
  parentRefs:
  - name: private    # GatewayClass: private
  - name: ts         # GatewayClass: home-ts  
  - name: public     # GatewayClass: public
status:
  parents:
  - controllerName: gateway.envoyproxy.io/gatewayclass-controller
    parentRef:
      name: ts
    # NO conditions field
  - controllerName: gateway.envoyproxy.io/gatewayclass-controller
    parentRef:
      name: private
    # NO conditions field
  - conditions:     # Only this one has conditions
    - type: Accepted
      status: "True"
    controllerName: gateway.envoyproxy.io/gatewayclass-controller
    parentRef:
      name: public

Root Cause

When processing EnvoyExtensionPolicy and SecurityPolicy, the code called GetRouteParentContext() for ALL parentRefs in the route, including those referencing gateways with different GatewayClasses not managed by the current translator instance.

GetRouteParentContext() creates a skeleton RouteParentStatus entry (with just controllerName and parentRef) when called on a parentRef that hasn't been processed yet. Since all GatewayClass instances use the same controller name (gateway.envoyproxy.io/gatewayclass-controller), these skeleton entries persisted without conditions.

Solution

Check if a parentRef context already exists before attempting to apply policy configuration. If it doesn't exist, skip it - this means the parentRef references a gateway not managed by this translator instance.

Fixes #7537

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.16%. Comparing base (c853061) to head (9b97c08).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/gatewayapi/envoyextensionpolicy.go	33.33%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7536      +/-   ##
==========================================
- Coverage   72.29%   71.16%   -1.14%     
==========================================
  Files         231      274      +43     
  Lines       34084    34862     +778     
==========================================
+ Hits        24641    24809     +168     
- Misses       7670     8259     +589     
- Partials     1773     1794      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zirain]

can you add a test case for this?

[arkodg]

does this fix have any intersection with #7307 (haven't looked closely yet)

[arkodg]

thanks @rajsinghtech, I took a real look at this and changes look good
can you add test yaml under internal/gatewayapi/testdata

also is a change needed in BTP as well ?

cc @y-rabie @zhaohuabing

[rajsinghtech]

Will add the test shortly, wasn't sure if I captured the full bug fix.

[arkodg]

yeah codex says, needs some changes in BTP

> - internal/gatewayapi/backendtrafficpolicy.go:284 – The described bug isn’t fully addressed. processBackendTrafficPolicyForRoute still calls GetRouteParentContext(targetedRoute, p, …) for every
  parentRef, so a BackendTrafficPolicy targeting an HTTPRoute that references multiple GatewayClasses will continue to create skeleton RouteParentStatus entries for the Gateways owned by other
  controllers. To make the fix complete you need the same guard you added elsewhere: fetch the context via targetedRoute.GetRouteParentContext(p), skip when it’s nil, and make sure the later loops
  that walk parentRefCtxs handle missing contexts. Otherwise the status bloat/problem remains whenever a BackendTrafficPolicy is present.

[zhaohuabing]

does this fix have any intersection with #7307 (haven't looked closely yet)

No, #7307 addresses another issue: it aggregates status across all GatewayClasses and performs a single consolidated update at the end, ensuring we can both preserve valid parent statuses and correctly remove those that no longer exist.

[rajsinghtech]

Added fix for BackendTrafficPolicy as well in commit 9b97c08.

Regarding tests: The existing test framework () simulates a single translator instance with a hardcoded GatewayClassName. The bug only manifests when multiple translators (one per GatewayClass) process the same HTTPRoute, which isn't directly testable in the current unit test structure.

However, the fix is straightforward:

• Before: Called GetRouteParentContext() which creates skeleton status entries
• After: Call route.GetRouteParentContext() which returns nil if the parentRef wasn't processed by this translator

The change prevents skeleton entries from being created when policies are applied to routes with multiple GatewayClasses.

[arkodg]

Added fix for BackendTrafficPolicy as well in commit 9b97c08.

Regarding tests: The existing test framework () simulates a single translator instance with a hardcoded GatewayClassName. The bug only manifests when multiple translators (one per GatewayClass) process the same HTTPRoute, which isn't directly testable in the current unit test structure.

However, the fix is straightforward:

• Before: Called GetRouteParentContext() which creates skeleton status entries
• After: Call route.GetRouteParentContext() which returns nil if the parentRef wasn't processed by this translator

The change prevents skeleton entries from being created when policies are applied to routes with multiple GatewayClasses.

you could achieve something similar in a test by adding a parentRef thats not part of the input, there will be failure in route status but also the before / after policy status should look different

[y-rabie]

@arkodg I think tests in https://github.com/envoyproxy/gateway/pull/7558/files#diff-c7323da3d9dfb378a30bb7b5a00c13ab9255ac810e2adfd9ec6dec6c9ef88a67R60-R116 cover this? The sequence is:

• Have a spec parentRef of ours and confirm it's in the status.
• Inject a status parentRef of another controller's, and confirm it lives alongside ours in the status (our controller doesn't remove it).
• Remove our spec parentRef and add the other controller's spec parentRef.
• Confirm that the status only contains the other controller's parentRef (we didn't remove it and we didn't add another one).

If they do, then I suggest we merge this PR without tests and use the tests in the other one, just for less conflicts and duplicated tests.

[arkodg]

LGTM thanks