Skip to content
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

replication_monitor/test: add diagnostic on assertion failure #20818

Merged
merged 1 commit into from
Jul 3, 2024

Conversation

bharathv
Copy link
Contributor

@bharathv bharathv commented Jul 2, 2024

Additionally reduces sleep durations to make the test faster.

Backports Required

  • none - not a bug fix
  • none - this is a backport
  • none - issue does not exist in previous branches
  • none - papercut/not impactful enough to backport
  • v24.1.x
  • v23.3.x
  • v23.2.x

Release Notes

  • none

Additionall reduces sleep durations to make the test faster.
@bharathv
Copy link
Contributor Author

bharathv commented Jul 2, 2024

Travis reported an issue here https://redpandadata.slack.com/archives/C05G315PGDR/p1719889095956289 where the test is failing to replicate even before the test does anything substantial, there is nothing in the log that indicates why (no drop of leadership etc). I looped through the test 1000s of times locally, couldn't reproduce, just adding additional error message when the test fails incase it reproduces again in CI 🤞 made it a bit quicker while I was there.

@piyushredpanda piyushredpanda merged commit 7685b6d into redpanda-data:dev Jul 3, 2024
14 of 19 checks passed
@bharathv bharathv deleted the rep_monitor_test branch July 3, 2024 22:06
ASSERT_FALSE_CORO(all.available());

for (auto i = 0; i < num_waiters(); i++) {
auto result = co_await raft->replicate(
make_batches({{"k", "v"}}),
replicate_options{raft::consistency_level::quorum_ack});
ASSERT_TRUE_CORO(result.has_value());
ASSERT_TRUE_CORO(result.has_value()) << result.error();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how the evaluation of the RHS of << would be optionally evaluated. Is it? If not, this looks like undefined behavior to me, calling .error() on a result type that has a value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the output from preprocessor.

switch (0)
case 0:
default:
  if (const ::testing::AssertionResult gtest_ar_ =
          ::testing::AssertionResult(result.has_value()))
    ;
  else
    co_return ::testing::internal::AssertHelper(
        ::testing::TestPartResult::kFatalFailure,
        "/work/redpanda/src/v/raft/tests/replication_monitor_tests.cc", 69,
        ::testing::internal::GetBoolAssertionFailureMessage(
            gtest_ar_, "result.has_value()", "false", "true")
            .c_str()) = ::testing::Message() << result.error()

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's crazy!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants