Intermittent test failure in PersistentTopicTest.testClosingReplicationProducerTwice
See original GitHub issueAs seen in
org.mockito.exceptions.verification.TooManyActualInvocations:
pulsarClientImpl.createProducerAsync(
"persistent://prop/global/ns/testClosingReplicationProducerTwice",
org.apache.pulsar.client.api.ProducerConfiguration@f74e835
);
Wanted 1 time:
-> at org.apache.pulsar.broker.service.PersistentTopicTest.testClosingReplicationProducerTwice(PersistentTopicTest.java:965)
But was 2 times. Undesired invocation:
-> at org.apache.pulsar.broker.service.AbstractReplicator.startProducer(AbstractReplicator.java:124)
at org.apache.pulsar.broker.service.PersistentTopicTest.testClosingReplicationProducerTwice(PersistentTopicTest.java:965)
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
How to Fix Flaky Tests - Semaphore CI
A test that intermittently fails for no apparent reason — or works in ... and fails with continuous integration — is called a...
Read more >Intermittent test failures when upgrading from 3.3 to 3.4.16
16 and I'm now seeing intermittent errors in my tests. The tests are using React and @testing-library/react with jest. The main issue is...
Read more >Flaky tests - GitLab Docs
When a test frequently fails in master , create a ~"failure::flaky-test" issue. If the test cannot be fixed in a timely fashion, there...
Read more >Fixing Flaky Time Based Unit Tests | by EG Tech - Medium
Another very common source of intermittent failures are tests that fail when they run:
Read more >How to reduce flaky test failures - CircleCI
It is essential to understand whether a test has failed due to flakiness or a genuine application issue. If it is a flaky...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Found the race. The builder stuff messed up this test completely, but the race is still there. Just put a 1s sleep after creating the replicator. Problem is ultimately that the mock should be applied before creating the replicator, because the replicator calls startProducer on construction, which will fail, and the call it again after a backoff, which is where the extra invokations are.
I’ll submit a patch tomorrow.
The fix is contributed by @ivankelly