-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
api: add a field in Listener proto to be able to reverse the order of TCP write filters #4889
Changes from 4 commits
fcd4fa0
fd65ede
72e1e77
fd13ec1
0acee1a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -135,7 +135,7 @@ HttpConnectionManagerConfig::HttpConnectionManagerConfig( | |||
Server::Configuration::FactoryContext& context, Http::DateProvider& date_provider, | ||||
Router::RouteConfigProviderManager& route_config_provider_manager) | ||||
: context_(context), reverse_encode_order_(PROTOBUF_GET_WRAPPED_OR_DEFAULT( | ||||
config, bugfix_reverse_encode_order, false)), | ||||
config, bugfix_reverse_encode_order, true)), | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It scares me that this change has no test implications? I guess because we have no integration test which covers this case? Can you potentially open a tech debt issue for someone to add a multi-filter encode/decode integration test? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are tests validating this. No test violation because we have set the default value true in the test, exercising the reversed order, see
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The tests are not actually validating this code change here, which is the real HCM config. (The tests use a mock/fake config.). This is why no other test changes were required when you made this change. Please add a config test here that would have failed with this change: https://github.com/envoyproxy/envoy/blob/master/test/extensions/filters/network/http_connection_manager/config_test.cc. Also please open the integration test tech debt issue I mentioned. We should have an integration test that uses multiple encode/decode filters. This should be a lot easier now given all the work that both @alyssawilk and @snowp have done with fake filters recently. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added a test case in config_test.cc to validate the hcm config, as well as a case in listener_manager_impl_test.cc to validate the listener config. IMO, the tests in I think the case, which is not tested as an e2e definition, is to consume the real hcm config from the proto and bring up real filters. If we are going to use fake filters in the e2e, the test cases seem already sufficient for me. Let me know if my understanding is correct. Happy to file a new issue for test tech debt if there is a need. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes I think this is fine, via the work that @snowp is doing now in the other PR we should be able to easily get coverage of multiple encoder filters in an integration test which is great. |
||||
stats_prefix_(fmt::format("http.{}.", config.stat_prefix())), | ||||
stats_(Http::ConnectionManagerImpl::generateStats(stats_prefix_, context_.scope())), | ||||
tracing_stats_( | ||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a PR to default this true for consistency, given the new default approach that was agreed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both fields for write and encoder filters, respectively, are default true in this PR. Should I explain more explicitly about the default value in the DEPRECATED.md file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine as is then.