-
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
quic: enabling some more tests #15381
quic: enabling some more tests #15381
Conversation
Signed-off-by: Alyssa Wilk <[email protected]>
3a4c278
to
ebb1798
Compare
Signed-off-by: Alyssa Wilk <[email protected]>
ebb1798
to
aaddfd5
Compare
Signed-off-by: Alyssa Wilk <[email protected]>
Signed-off-by: Alyssa Wilk <[email protected]>
Signed-off-by: Alyssa Wilk <[email protected]>
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.
Thanks for fixing some of the quic issues!
FYI, I'm working on adding downstream Http3 tests: https://github.com/envoyproxy/envoy/compare/main...danzh2010:addprotointegrationtest?expand=1
} | ||
|
||
return Http::FilterHeadersStatus::Continue; | ||
} | ||
|
||
Http::FilterDataStatus encodeData(Buffer::Instance& data, bool end_stream) override { | ||
// For HTTP/3, there's no headers-only streams so the data will be added here. | ||
ASSERT(end_stream == false || decoder_callbacks_->connection()->streamInfo().protocol()); |
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.
What is decoder_callbacks_->connection()->streamInfo().protocol()
for? comment?
// TODO(danzh) this should run with QUIC downstream instead of HTTP2. | ||
INSTANTIATE_TEST_SUITE_P(Protocols, DownstreamProtocolIntegrationTest, | ||
testing::ValuesIn(HttpProtocolIntegrationTest::getProtocolTestParams( | ||
{Http::CodecClient::Type::HTTP2}, {FakeHttpConnection::Type::HTTP3})), |
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.
suggest to test HTTP and HTTP2 for downstream as well. I will add another test suite for downstream HTTP3.
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.
those are tested in test/integration/instantiate_protocol_integration_test.cc so I think we're good?
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.
I find a test for h3 downstream work for H1 but not H2 upstream. So worth to run both I think.
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.
How about I land this as-is, and after yours is, see if adding the extras nets anything new? I'm mildly skeptical it will and either way I think incremental change should be fine.
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.
SGTM
Signed-off-by: Alyssa Wilk <[email protected]>
Signed-off-by: Alyssa Wilk <[email protected]>
} else { | ||
headers.removeContentLength(); |
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.
Why would we hit this if this is used with header only requests?
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.
header only request doesn't mean the fin bit arrives with the headers, in the case of QUIC.
will comment.
// For HTTP/3, the only time the protocol is set at the connection level, there's no | ||
// headers-only streams so the data will be added here. | ||
ASSERT(end_stream == false || decoder_callbacks_->connection()->streamInfo().protocol()); |
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.
This still seems a bit confusing to me, when do we expect end_stream=false and when do we expect the protocol to be set?
} | ||
|
||
private: | ||
constexpr static absl::string_view body_ = "body"; | ||
// For HTTP/3 upstream, the headers and fin will arrive separately. |
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.
so when we say that HTTP/3 doesn't have header only its because we'd at least expect to see a headers(end_stream=false) with an empty data(end_stream=true)? Seems not great that we have all these differences in callback usage
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.
largely these tests make sure you can go from
headers + fin
to
headers + body + fin.
for QUIC, we just insert the data at a different part of the pipeline. I still think it's important to make sure it works.
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.
Makes sense! I think I'm just worried about filter authors having to be aware of all these variations in callback patterns, but this isn't something we need to address in this PR
@@ -501,6 +500,11 @@ TEST_P(ProtocolIntegrationTest, Retry) { | |||
TestUtility::findCounter(stats, "cluster.cluster_0.http2.tx_reset"); | |||
ASSERT_NE(nullptr, counter); | |||
EXPECT_EQ(1L, counter->value()); | |||
} else if (upstreamProtocol() == FakeHttpConnection::Type::HTTP3) { | |||
Stats::CounterSharedPtr counter = | |||
TestUtility::findCounter(stats, "cluster.cluster_0.upstream_rq_tx_reset"); |
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 we not want a http3 stats scope to match the other branches here?
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.
I think landing this will help a few tests over in #15424 so would prefer to fix in a follow-up. added TODO!
@@ -731,6 +736,7 @@ TEST_P(DownstreamProtocolIntegrationTest, RetryAttemptCountHeader) { | |||
// The retry priority will always target P1, which would otherwise never be hit due to P0 being | |||
// healthy. | |||
TEST_P(DownstreamProtocolIntegrationTest, RetryPriority) { | |||
EXCLUDE_UPSTREAM_HTTP3; |
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.
maybe include some indication of why these are failing under http/3?
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.
there's a TODO to address all of these where I declare the macro so if I can avoid classifying for now that'd be helpful (I have WIP PRs for about 80% but I don't recall offhand which are which =P)
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.
Sure, sgtm!
Signed-off-by: Alyssa Wilk <[email protected]>
Signed-off-by: Alyssa Wilk <[email protected]>
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.
LGTM
Enabling (most of the) the downstream tests for quic upstream for more coverage.
Enabling cookie tests given Dan's fix
Fixing a couple of tests with filters assuming headers-come-with-fin
Defaulting header size to Envoy defaults.
Risk Level: low (quic / test code)
Testing: yes
Docs Changes: n/a
Release Notes: n/a
part of #14829