fix(status): align BackendTLSPolicy ResolvedRefs reason with Gateway API

[Aditya7880900936]

What type of PR is this?

fix: correct BackendTLSPolicy ResolvedRefs reason

---

What this PR does / why we need it:

Envoy Gateway was setting the ResolvedRefs=False condition reason to
InvalidKind for BackendTLSPolicy when a referenced CA certificate could
not be resolved.

According to Gateway API conformance and the BackendTLSPolicy specification,
this scenario must use the InvalidCACertificateRef reason. This PR updates
the status reason and adjusts golden test outputs to align with the expected
behavior.

---

Which issue(s) this PR fixes:

Fixes #7790

---

Release Notes: No

[codecov]

Codecov Report

❌ Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 72.84%. Comparing base (c1931a6) to head (947113b).
⚠️ Report is 18 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/gatewayapi/backendtlspolicy.go	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7793      +/-   ##
==========================================
+ Coverage   72.61%   72.84%   +0.22%     
==========================================
  Files         235      235              
  Lines       34876    35175     +299     
==========================================
+ Hits        25325    25622     +297     
+ Misses       7745     7738       -7     
- Partials     1806     1815       +9     

☔ 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.

[Aditya7880900936]

The conformance test failures appear to be related to GatewayClass acceptance timing (proxy-config not found / context deadline exceeded) and not BackendTLSPolicy behavior.

My change only affects BackendTLSPolicy status reason mapping and does not touch GatewayClass, EnvoyProxy, or control-plane startup logic.

Happy to re-run or adjust if maintainers think this is related.

[Aditya7880900936]

Hi @arkodg ,
just tagging you for a quick look when you get a chance.

This PR only updates the BackendTLSPolicy status reason mapping; the current failures appear to be unrelated conformance flakes.

Happy to rebase, rerun, or adjust based on your guidance. Thanks!

[Aditya7880900936]

Hi @zirain 👋

Apologies for the ping — just looking for a quick sanity check when you get a chance.

This PR aligns BackendTLSPolicy ResolvedRefs status reason with the Gateway API spec.
The current CI failures appear to be unrelated conformance flakes (GatewayClass / proxy startup timing), not caused by this change.

I’ve added context above and can re-run or rebase if needed.
Thanks for taking a look!

[Aditya7880900936]

Hi @arkodg ,
just tagging you for a quick look when you get a chance.

This PR only updates the BackendTLSPolicy status reason mapping; the current failures appear to be unrelated conformance flakes.

Happy to rebase, rerun, or adjust based on your guidance. Thanks!

[arkodg]

instead of deleting the logic, is there an issue with the current logic of

	if errors.Is(err, ErrBackendTLSPolicyInvalidKind) {
			reason = gwapiv1.BackendTLSPolicyReasonInvalidKind
		}

is the right err being returned ?

[Aditya7880900936]

Hi @arkodg ,
Good question — the error is being returned, but it’s semantically overloaded.

ErrBackendTLSPolicyInvalidKind is currently returned from getCaCertsFromCARefs when no CA bundle could be resolved (e.g. missing key, missing object, empty result), not when the reference kind itself is invalid.

Because of that, the error does not reliably indicate an invalid reference kind per the Gateway API semantics. In practice it represents a CA resolution failure, which the spec and conformance tests map to InvalidCACertificateRef.

That’s why I removed the conditional mapping — keying ResolvedRefs on this error was causing valid CA-resolution failures to be reported as InvalidKind.

If you think we should distinguish these cases more explicitly, I’m happy to follow up with a separate change that introduces a dedicated error for truly invalid reference kinds.

[arkodg]

gateway/internal/gatewayapi/backendtlspolicy.go

Line 517 in 721e62d

if ca == "" {

needs to be improved to better decipher between invalid kind and other failure cases

[Aditya7880900936]

That makes sense 👍

I’ll update getCaCertsFromCARefs to explicitly return an error for truly invalid
reference kinds and use a separate error for CA resolution failures. That should
allow ResolvedRefs to correctly distinguish InvalidKind vs
InvalidCACertificateRef.

I’ll push an updated revision shortly.

[Aditya7880900936]

Hi @arkodg
Thanks for the review and the clarification.

I’ve updated the error classification for CA resolution failures so that missing or unusable CA bundles use a more accurate error, allowing the status to consistently report InvalidCACertificateRef without altering validation logic.

All tests pass locally (go test ./..., make test).

[jukie]

This looks good, thanks! Could you confirm that the new conformance test in kubernetes-sigs/gateway-api#4360 passes here?

[Aditya7880900936]

Hi @jukie @arkodg
Thanks for the heads-up.

It looks like the current CI failures are occurring during Helm chart linting, before the Gateway API conformance assertions run. I’ve updated the branch to pick up the latest changes from main and will confirm the result once the conformance tests complete.

[arkodg]

more plumbing is needed here
ca == "" could mean a Get returned nothing or it never entered the for loop block or it never entered the switch block

[Aditya7880900936]

Hi @arkodg ,
Thanks for the review!
I’ve updated the implementation to distinguish invalid CA kinds vs missing/empty CA bundles, updated the expected test output, and ensured DCO compliance.
All gatewayapi tests are passing locally. Please let me know if you’d like this handled differently.

[Aditya7880900936]

Hi @arkodg, just a gentle follow-up in case this got buried.
Happy to make any further changes if needed. Thanks!

[arkodg]

can you add a test case