Codecov Report

❌ Patch coverage is 0% with 57 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.69%. Comparing base (6f42531) to head (d0b7987).
⚠️ Report is 295 commits behind head on main.

❌ Your patch status has failed because the patch coverage (0.00%) is below the target coverage (60.00%). You can increase the patch coverage or adjust the target coverage.

@@            Coverage Diff             @@
##             main    #6153      +/-   ##
==========================================
- Coverage   70.80%   70.69%   -0.12%     
==========================================
  Files         220      220              
  Lines       37132    37189      +57     
==========================================
- Hits        26291    26289       -2     
- Misses       9300     9358      +58     
- Partials     1541     1542       +1     

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

This fix takes a different approach from #4587 because #4587 has a loophole - the status merging logic can't delete an old status ancestor after a target is removed. I plan to raise a follow-up PR to fix that using the same strategy if we agree on this one.

We still have another issue: if the selector changes and no targets are selected anymore, the existing status can't be deleted. This is because the current translator ignores the xPolicy without targets and won't update their statuses. This will be addressed in a separate PR.

@zhaohuabing dont xRoutes status have the same issue ? I believe we solved those in the provider status updater layer ?

@zhaohuabing dont xRoutes status have the same issue ? I believe we solved those in the provider status updater layer ?

@arkodg Yes, we fixed a similar issue for xRoute in #4587, but I prefer this solution because the xRoute fix has a loophole, more in this comment: #6153 (comment)

hey @zhaohuabing thanks for sharing the past history :) , this looks like two issues

1. around cleaning up old status condition entries. can we solve this with a separate util function similar to mergeRouteParentStatus that removes any condition (linked to EG controller) whose ObservedGeneration doesnt match the current ObservedGeneration of the client Object ?
   2 ) Regarding this specific issue of multiple Gateways linked to different GatewayClasses, this feels like we need to change the ancestor to GatewayClass instead of Gateway and merge properly in the status update layer ?

1. around cleaning up old status condition entries. can we solve this with a separate util function similar to mergeRouteParentStatus that removes any cond

Agree.

2 ) Regarding this specific issue of multiple Gateways linked to different GatewayClasses, this feels like we need to change the ancestor to GatewayClass instead of Gateway and merge properly in the status update layer ?

I have no strong opinion on this. Things we may need to consider regarding Gateway vs GatewayClass as the policy status ancestor:

• Gateway API recommends using Gateway as the ancestor if there are no special reasons.
• It feels more intuitive to use Gateway as the parent, as policy targets Gateways and routes.

with Gateway as the ancestor, we cannot create unique status conditions, because the conditions may vary across Gateway linked to different GatewayClasses

around cleaning up old status condition entries. can we solve this with a separate util function similar to mergeRouteParentStatus that removes any condition (linked to EG controller) whose ObservedGeneration doesnt match the current ObservedGeneration of the client Object ?

Thought it again - this can't be solved by ObservedGeneration.
ObservedGeneration comes form the Generation of the xPolicy resource, however, the xPolicy status can change without a bump of its Generation.
For example:
a xPolicy targets a Gateway gw. After gw is deleted, it's still in the status of xPolicy, and this status can't be cleaned because the ObservedGeneration of status is the same as the policy.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  generation: 11
  name: test
spec:
  connection:
    bufferLimit: 100M
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: gw
status:
  ancestors:
  - ancestorRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gw
      namespace: default
    conditions:
    - lastTransitionTime: "2025-06-25T00:55:28Z"
      message: Policy has been accepted.
      observedGeneration: 11
      reason: Accepted
      status: "True"
      type: Accepted
    controllerName: gateway.envoyproxy.io/gatewayclass-controller

@zhaohuabing same is true for xRoute and linked resources ( backendRef)

with Gateway as the ancestor, we ca

You mean this issue #774 ? I'm planning to work on that after fixing the xPolicy status.

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!