Uploaded image for project: 'Debezium'
  1. Debezium
  2. DBZ-2268 Intermittent test failures
  3. DBZ-2544

Intermittent test failure on CI - PostgresConnectorIT#customSnapshotterSkipsTablesOnRestart()

      See https://api.travis-ci.org/v3/job/727725812/log.txt

      [ERROR] Tests run: 54, Failures: 1, Errors: 0, Skipped: 2, Time elapsed: 162.505 s <<< FAILURE! - in io.debezium.connector.postgresql.PostgresConnectorIT
      [ERROR] customSnapshotterSkipsTablesOnRestart(io.debezium.connector.postgresql.PostgresConnectorIT)  Time elapsed: 28.465 s  <<< FAILURE!
      java.lang.AssertionError: expected size:<0> but was:<1> for <['idle in transaction']>
      	at io.debezium.connector.postgresql.PostgresConnectorIT.customSnapshotterSkipsTablesOnRestart(PostgresConnectorIT.java:1493)
      

            [DBZ-2544] Intermittent test failure on CI - PostgresConnectorIT#customSnapshotterSkipsTablesOnRestart()

            Released

            Jiri Pechanec added a comment - Released

            Chris Cranford added a comment - - edited

            So I think part of the problem with this unit test is how assertNoOpenTransaction is written. The method actually performs the database check in 2 spots and when we observe the test failure, its on the second assertion check. Instead, I think we should continue to use the Awaitility call, checking periodically for the expected database state and if and only if the Awaitility call fails with a time-out should we fail the test; otherwise if the Awaitility call succeeds, that should be sufficient and the second assertion call can be removed.

            Chris Cranford added a comment - - edited So I think part of the problem with this unit test is how assertNoOpenTransaction is written. The method actually performs the database check in 2 spots and when we observe the test failure, its on the second assertion check. Instead, I think we should continue to use the Awaitility call, checking periodically for the expected database state and if and only if the Awaitility call fails with a time-out should we fail the test; otherwise if the Awaitility call succeeds, that should be sufficient and the second assertion call can be removed.

              ccranfor@redhat.com Chris Cranford
              gunnar.morling Gunnar Morling
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: