retry mqtt stream test that fails a lot

[pjfanning]

this line times out 50% of the time in our CI runs - eg https://github.com/apache/incubator-pekko-connectors/actions/runs/5561095341/jobs/10158693141#step:5:674

see #148

[mdedetrich]

I am pretty sure have already increase the timeout for this test and it didn't appear to make an ultimate impact, I think the flakiness is elsewhere.

[pjfanning]

I think the test case is actually broken - that it's not a time out issue. With the eventually, the test is at least retried. That is not the ultimate solution but the problem is that until we fix this test, it is causing so many build failures - we need to either set the test to be ignored or retry the test with an eventually until someone has time to fix it altogether.

[pjfanning]

I am pretty sure have already increase the timeout for this test and it didn't appear to make an ultimate impact, I think the flakiness is elsewhere.

Is it ok to get the test to retry until someone has the time to look into why this test is so flaky. It fails so many of our builds that the test is now just pure noise.

[pjfanning]

@nvollmar @mdedetrich @kerr - could we consider merging this as short term solution to all the broken builds?

[pjfanning]

@nvollmar @mdedetrich @kerr - could we consider merging this as short term solution to all the broken builds?

[mdedetrich]

I didn't have a look at the PR because to me it seemed like it was overengineered and that maybe the best solution would be to use something like scalatest's https://www.scalatest.org/scaladoc/3.0.8/org/scalatest/Retries.html ?

If we are not solving the core issue behind way the test is flaky I have a preference for using techniques such as ScalaTest Retries, or put differently I have an aversion to modifying a test a lot unless its actually solving the core problem.

[pjfanning]

I didn't have a look at the PR because to me it seemed like it was overengineered and that maybe the best solution would be to use something like scalatest's https://www.scalatest.org/scaladoc/3.0.8/org/scalatest/Retries.html ?

If we are not solving the core issue behind way the test is flaky I have a preference for using techniques such as ScalaTest Retries, or put differently I have an aversion to modifying a test a lot unless its actually solving the core problem.

The change here is not very big - the main cause of the diff is the eventually block indents the code inside the block

[mdedetrich]

The change here is not very big - the main cause of the diff is the eventually block indents the code inside the block

Ah I see, I set the hide whitespace option and I see the diff is indeed trivial and you appear to be using the right scalatast abstraction for this, i.e. eventually.

lgtm

[nvollmar]

In cases where we anyway just retrigger the failed test runs it makes sense as long as there is an open issue and have a link to it to eventually address this. There is also a flaky test in the persistence cassandra project I've yet failed to find the root cause that it would make sense to apply this.