Flaky PartitionTransitionImplTest.shouldAbortOngoingTransitionWhenNewTransitionIsRequested

[npepinpe]

Summary

• How often does the test fail?
  • Twice
• Does it block your work?
  • No
• Do we suspect that it is a real failure?
  • Likely not

Failures

Example assertion failure

java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:385)
	at java.base/java.util.ArrayList.remove(ArrayList.java:551)
	at io.camunda.zeebe.broker.system.partitions.impl.PartitionTransitionProcess.lambda$proceedWithTransition$1(PartitionTransitionProcess.java:88)
	at io.camunda.zeebe.scheduler.testing.TestConcurrencyControl.run(TestConcurrencyControl.java:50)

[oleschoenburg]

I couldn't reproduce this yet. The exception says that PartitionTransitionProcess tries to remove from pendingSteps but it's empty. As far as I can tell, this can only happen if PartitionTransitionProcess isn't thread safe. Since the test uses TestConcurrencyControl which behaves differently to the production version, I suspect a concurrency issue that is test-only and difficult to trigger.