What would you like to be added:
When the translator records any semantic translation failure for an XAccessPolicy during Gateway xDS generation, that policy must be fully excluded from dataplane configuration for that reconcile pass:
Do not translate or apply any rules from that policy (RBAC at gateway/backend, ext_authz, etc.).
Continue to set policy-level status from #236: Accepted=False, PolicyReasonInvalid, with aggregated error messages.
Implementation should treat policies present in the translation issues map as non-enforceable for the current spec (all-or-nothing at the policy object), aligned with Gateway API HTTPRoute-style behavior and maintainer feedback on #236.
Why this is needed:
#236 (#233) fixes visibility: users see Accepted=False / Invalid when translation fails. It does not fix enforcement: the translator can still skip failing rules and apply the rest of the same policy in Envoy.
That creates a security and consistency gap:
Effective behaviour ≠ declared spec — users may believe the full policy failed, while Envoy still enforces surviving rules.
Misleading operational model — status says the policy is invalid, but the dataplane is partially protected by that policy.
The long-term model should reject the entire policy at translate time, not partial enforcement or rule-level status.
What would you like to be added:
When the translator records any semantic translation failure for an XAccessPolicy during Gateway xDS generation, that policy must be fully excluded from dataplane configuration for that reconcile pass:
Do not translate or apply any rules from that policy (RBAC at gateway/backend, ext_authz, etc.).
Continue to set policy-level status from #236: Accepted=False, PolicyReasonInvalid, with aggregated error messages.
Implementation should treat policies present in the translation issues map as non-enforceable for the current spec (all-or-nothing at the policy object), aligned with Gateway API HTTPRoute-style behavior and maintainer feedback on #236.
Why this is needed:
#236 (#233) fixes visibility: users see Accepted=False / Invalid when translation fails. It does not fix enforcement: the translator can still skip failing rules and apply the rest of the same policy in Envoy.
That creates a security and consistency gap:
Effective behaviour ≠ declared spec — users may believe the full policy failed, while Envoy still enforces surviving rules.
Misleading operational model — status says the policy is invalid, but the dataplane is partially protected by that policy.
The long-term model should reject the entire policy at translate time, not partial enforcement or rule-level status.