-
Notifications
You must be signed in to change notification settings - Fork 5.5k
test: deflaking a test, improving debugability #3829
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
Changes from 2 commits
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 |
|---|---|---|
|
|
@@ -16,6 +16,21 @@ namespace Envoy { | |
| } \ | ||
| } while (false) | ||
|
|
||
| /** | ||
| * A version of RELEASE_ASSERT that allows for ostream style extra data. | ||
| */ | ||
| #define VERBOSE_RELEASE_ASSERT(X, Y) \ | ||
|
Member
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. I think we want something closer to what happens in |
||
| do { \ | ||
| if (!(X)) { \ | ||
| std::ostringstream stream; \ | ||
| stream << Y; \ | ||
|
Member
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. Should this be |
||
| std::string details = stream.str(); \ | ||
| ENVOY_LOG_TO_LOGGER(Envoy::Logger::Registry::getLog(Envoy::Logger::Id::assert), critical, \ | ||
| "assert failure: {}. Details: {} ", #X, details); \ | ||
| abort(); \ | ||
| } \ | ||
| } while (false) | ||
|
|
||
| #ifndef NDEBUG | ||
| #define ASSERT(X) RELEASE_ASSERT(X) | ||
| #else | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| #include "common/common/assert.h" | ||
|
|
||
| #include "gtest/gtest.h" | ||
|
|
||
| TEST(Assert, VariousLogs) { | ||
| EXPECT_DEATH({ RELEASE_ASSERT(0); }, ".*assert failure: 0.*"); | ||
| EXPECT_DEATH({ VERBOSE_RELEASE_ASSERT(0, "With some logs"); }, | ||
| ".*assert failure: 0. Details: With some logs.*"); | ||
| EXPECT_DEATH( | ||
| { | ||
| VERBOSE_RELEASE_ASSERT(0, "With multiple " | ||
| << "logs"); | ||
| }, | ||
| ".*assert failure: 0. Details: With multiple logs.*"); | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -368,11 +368,11 @@ void Http2IntegrationTest::simultaneousRequest(int32_t request1_bytes, int32_t r | |
| EXPECT_EQ(request2_bytes, response1->body().size()); | ||
|
|
||
| // Cleanup both downstream and upstream | ||
| codec_client_->close(); | ||
| fake_upstream_connection1->close(); | ||
| fake_upstream_connection1->waitForDisconnect(); | ||
| fake_upstream_connection2->close(); | ||
| fake_upstream_connection2->waitForDisconnect(); | ||
| codec_client_->close(); | ||
|
Member
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. Can you add a comment explaining how the ordering here matters/helps?
Contributor
Author
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. This one doesn't actually matter. I added it in case future code copy-pasted and it did matter. |
||
| } | ||
|
|
||
| TEST_P(Http2IntegrationTest, SimultaneousRequest) { simultaneousRequest(1024, 512); } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -214,13 +214,17 @@ IntegrationStreamDecoderPtr HttpIntegrationTest::sendRequestAndWaitForResponse( | |
| } | ||
|
|
||
| void HttpIntegrationTest::cleanupUpstreamAndDownstream() { | ||
| if (codec_client_) { | ||
| codec_client_->close(); | ||
| } | ||
| // Close the upstream connection first. If there's an outstanding request, | ||
| // closing the client may result in a FIN being sent upstream, and FakeConnectionBase::close | ||
| // will interpret that as an unexpected disconnect. The codec client is not | ||
| // subject to the same failure mode. | ||
|
Member
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. Like this comment ;) |
||
| if (fake_upstream_connection_) { | ||
| fake_upstream_connection_->close(); | ||
| fake_upstream_connection_->waitForDisconnect(); | ||
| } | ||
| if (codec_client_) { | ||
| codec_client_->close(); | ||
| } | ||
| } | ||
|
|
||
| void HttpIntegrationTest::waitForNextUpstreamRequest(uint64_t upstream_index) { | ||
|
|
||
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.
Should this just be the
RELEASE_ASSERTimplementation in the interest of economy of mechanism?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.
FWIW, I've wanted something like this for a while, so I would be in favor of adding this.
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.
Cool. If you're up for it, I'm all for doing the more invasive ostream style default-release-assert. And possibly moving the other asserts over as well.
I think at that point I'll probably split it out of the test flake PR though :-)
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.
Any reason not to use the existing fmtlib-style for this?
Uh oh!
There was an error while loading. Please reload this page.
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.
My weak argument is to be consistent with the ASSERT_EQ/EXPECT_EQ code in test but the real reason is I like ostream way better. I believe that fmt is more consistent with the code base so alternately I could look into a variable [1 or 2] argument macro with a fmt string as the second argument.
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 prefer consistency with the code base, but I don't feel strongly about it. Anyone else have an opinion on this?
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.
An argument in favor of ostream is that if we implement it that way, we can easily add the fmtlib variant as a wrapper on top, e.g.
so, doing it ostream provides maximum flexibility.
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.
No strong opinion from me. Whatever you all think is best. Happy to see this land though, there are many times in prod code when I think it would be nice to actually have a more detailed message of a RELEASE_ASSERT() (I would go as far as to say we should ultimately audit all uses and force everyone to use the new version). Agree this can be split out though...