Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-15672

Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec

    XMLWordPrintableJSON

Details

    • Correctness
    • Normal
    • Normal
    • User Report
    • All
    • None
    • Hide

      I ran CoordinatorMessagingTest several hundred times and it turned out that there is more than 1 flaky test. testMockedMessagingHappyPath and all tests that execute testMockedMessagingPrepareFailure fail from time to time.

      In testMockedMessagingHappyPath we check whether sessionResult.isDone after each step of repair communication and assert that it will only be true after the final step. However, doing these assertions we cannot be sure that the final step hasn't been finished yet. Without 208a23 this test fails ~10 times during 500 executions.

      There is a similar issue with testMockedMessagingPrepareFailure. We check that there are no failures yet right after starting coordinator execution. If we are unlucky and at least one of the participants that is meant to fail responds before we load proposeFailed, the assertion will fail. b3c761 removes the flaky assertion.

      Additionally I included small javadoc fixes in a6e9d0.

      Show
      I ran CoordinatorMessagingTest several hundred times and it turned out that there is more than 1 flaky test. testMockedMessagingHappyPath and all tests that execute testMockedMessagingPrepareFailure fail from time to time. In testMockedMessagingHappyPath we check whether sessionResult.isDone after each step of repair communication and assert that it will only be true after the final step. However, doing these assertions we cannot be sure that the final step hasn't been finished yet. Without 208a23 this test fails ~10 times during 500 executions. There is a similar issue with testMockedMessagingPrepareFailure . We check that there are no failures yet right after starting coordinator execution. If we are unlucky and at least one of the participants that is meant to fail responds before we load proposeFailed , the assertion will fail. b3c761 removes the flaky assertion. Additionally I included small javadoc fixes in a6e9d0 .

    Description

      The following failure was observed:

      Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
      [junit-timeout]
      [junit-timeout] Testcase: testMockedMessagingPrepareFailureP1(org.apache.cassandra.repair.consistent.CoordinatorMessagingTest): FAILED
      [junit-timeout] null
      [junit-timeout] junit.framework.AssertionFailedError
      [junit-timeout] at org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailure(CoordinatorMessagingTest.java:206)
      [junit-timeout] at org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailureP1(CoordinatorMessagingTest.java:154)
      [junit-timeout]
      [junit-timeout]

      Seen on Java8

      Attachments

        Issue Links

          Activity

            People

              Gerrrr Alex Sorokoumov
              e.dimitrova Ekaterina Dimitrova
              Alex Sorokoumov
              Stefania Alborghetti
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 20m
                  20m