The GitHub Actions job "Nightly Builds" on pekko.git/main has failed. Run started by GitHub user He-Pin (triggered by He-Pin).
Head commit for run: ebddbc2112059e7aa74de7d80589a2085401c94e / He-Pin(kerr) <[email protected]> test: stabilize two flaky tests on JDK21+/virtualized nightly (#2949) * test: stabilize resizer performance log sampling Motivation: The "record the performance log with the correct pool size" test in MetricsBasedResizerSpec is intermittently flaky on JDK21+/JDK25 nightly runs (e.g. apache/pekko#25586760215, ~12s before failing on JDK 25 / Scala 2.13.x with virtualized dispatchers). Between the two reportMessageCount checkpoints the test sent only one extra mockSend per routee. With virtual-thread scheduling those extra messages can be processed before the second reportMessageCount runs, leaving routees idle (currentMessage = null) so messagesInRoutees underestimates the queue and the resizer's fullyUtilized check falls through, no performance log is recorded, and the final assertion fails with "None was empty". Modification: Replace the inter-checkpoint mockSend pair with a second sendToAll call (await=false) and Await.ready on its first latch. This keeps both routees actively holding their currentMessage when reportMessageCount runs, so the resizer always observes the routees as fully utilized across the two checkpoints. Result: The test no longer relies on routees still being busy by chance after their previous batch completes, and runs deterministically on virtualized dispatchers. * test: drop racy pre-shutdown closedCounter check in autocloseable abrupt-termination test Motivation: "will close the autocloseable resource on abrupt materializer termination" in FlowMapWithResourceSpec is intermittently flaky on JDK 21 / Scala 3.3.x nightly runs (failing in 22-115ms with "1 was not equal to 0" at FlowMapWithResourceSpec.scala:538). mapWithResource carries the IODispatcher attribute which lands the operator on a different dispatcher than Source.single and Sink.never, introducing an async-island bridge whose SubSink can pull eagerly. Once that pull propagates back, Source.single pushes its element and completes, StatefulMap.onUpstreamFinish fires, closeStateAndComplete runs the close callback and the AutoCloseable counter reaches 1 before the test thread issues mat.shutdown(). The pre-shutdown "closedCounter.get shouldBe 0" therefore loses the race on fast JDK21+ scheduling. Modification: Remove the pre-shutdown closedCounter assertion. The test still proves the abrupt-termination contract via the Await on created.future (ensuring create() ran), the AbruptTerminationException assertion on the materialized value, the Await on promise.future (ensuring close() ran) and the post-shutdown closedCounter == 1 check. Result: Removes a timing assumption that doesn't reflect the operator's contract, while keeping the close-on-abrupt-termination guarantee under verification. Report URL: https://github.com/apache/pekko/actions/runs/25599287529 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
