refactor: return 500 when BackendTLSPolicy translation fails
What type of PR is this?
What this PR does / why we need it:
- 500 for HTTP
- connection reset for TCP/UDP
Which issue(s) this PR fixes: Fixes https://github.com/envoyproxy/gateway/issues/4087
Codecov Report
Attention: Patch coverage is 81.62162% with 34 lines in your changes missing coverage. Please review.
Project coverage is 66.28%. Comparing base (
b9f9a9f) to head (c2c8b4b). Report is 1 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #4363 +/- ##
==========================================
- Coverage 66.29% 66.28% -0.01%
==========================================
Files 209 209
Lines 31912 31956 +44
==========================================
+ Hits 21157 21183 +26
- Misses 9507 9523 +16
- Partials 1248 1250 +2
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
/retest
/retes
/retest
/retest
/retest
/retest
@alexwo I dont see the conformance tests passing. I'm worried about the size of this change that not only applies to BTP but every error while translating route rules and backendRefs. For example if one out of the many backendRefs is invalid, only a portion of the requests should receive a 503 https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.HTTPBackendRef
@alexwo I dont see the conformance tests passing. I'm worried about the size of this change that not only applies to BTP but every error while translating route rules and backendRefs. For example if one out of the many backendRefs is invalid, only a portion of the requests should receive a 503 https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.HTTPBackendRef
@arkodg indeed, the impact of the change is large and it will render out many of the partial working, not fully configured routes, I can fully relate to it.
We should be covered as long as many of the necessary tests should be in place,what can detect potential issues.
The conformance tests are passing, but there was a linting issue previously that prevented them from running.
Now, if a part of the backend reference configuration is invalid — for example, if one of the associated configurations cannot be processed — the key question is: should routing to this backend reference still occur in such cases?
/retest
Now, if a part of the backend reference configuration is invalid — for example, if one of the associated configurations cannot be processed — the key question is: should routing to this backend reference still occur in such cases?
According to the spec, the answer is a portion of the requests (based on weights) should continue to be sent to the valid backendRef
Now, if a part of the backend reference configuration is invalid — for example, if one of the associated configurations cannot be processed — the key question is: should routing to this backend reference still occur in such cases?
According to the spec, the answer is a portion of the requests (based on weights) should continue to be sent to the valid backendRef
We’re processing all backend routes and addressing only falty configured ones. This should ensures alignment with the spec, as valid backend routes will continue to function, while only those with invalid configurations will be skipped / not translated. ( we process all routes for each backend and go over all routes, even if some one the backend routes did have errors . )
/retest
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!
/retest
/retest
/retest
/retest