De-flake ReceiveTimeoutSpec: measure the two timeout cycles with dilated probe waits instead of one flat latch

[Aaronontheweb]

What changes

ReceiveTimeoutSpec stops waiting on latches built with new TestLatch(...) and waits on TestProbes instead. The first commit rewrote the two tests that failed; the second migrates the remaining seven synchronous facts the same way, so no blocking wait is left in the file.

• An_actor_with_receive_timeout_must_get_timeout_while_receiving_only_NotInfluenceReceiveTimeout_messages now awaits three probe messages in order: "timeout", then "tick", then "timeout". Each wait has its own dilated budget: 1 s plus 4 s of slack for a timeout cycle, 1 s for the tick, which is a local self-send. It also now proves the transparent tick was delivered between the two timeouts, which the old latch could not.
• An_actor_with_receive_timeout_must_not_receive_timeout_message_when_not_specified now asserts with ExpectNoMsgAsync instead of catching a TimeoutException from a blocking 5 s latch wait.

Why

The first test failed on CI build 131165 after exactly 5 s. The product is correct: a message marked INotInfluenceReceiveTimeout cannot cancel or re-arm the pending timer, and the code matches Pekko line for line. Two things in the test made it fragile:

• A latch built with new TestLatch(n) never dilates its timeout, unlike one built with CreateTestLatch(), so its 5 s wall ignores akka.test.timefactor. The earlier fix in Fix flaky ReceiveTimeoutSpec CI timeout #8153 helped the sibling test that uses the helper and could not help this one. About 83 call sites in the repo build latches this way.
• The test parked a thread-pool worker in a blocking wait while it measured two consecutive 1 s scheduler cycles. On the net10.0 lane the scheduler's clock loop, the actor's mailbox, and the test all share the .NET thread pool, whose floor is the processor count because xUnit v3 only raises it on its parallel path and Akka.Tests disables parallelization. On a 2-vCPU agent one worker ran everything, and any stall landed on the timer. Because the receive timeout is re-armed after the handler returns, lateness in the first cycle was added to the second.

Second commit: the remaining facts

The three test actors take a probe instead of a latch and send "timeout" when the receive timeout fires. The seven remaining facts become async and await the probe with the same budget the latch had, or a receive-timeout plus 4 s where the fact measures a 1 s cycle, as the first commit does. The turn-off fact asserts with ExpectNoMsgAsync instead of catching a TimeoutException from a 1 s latch wait. The issue-469 fact keeps its probe apart from the test actor so the dead-letter check stays separate. A grep for synchronous TestKit calls and Ready( on the file returns nothing. The class run three times: 10 of 10 each time.

How it was checked

dotnet build src/core/Akka.Tests -c Release -warnaserror clean. The rewritten test run 25 times in a row: 25 passes, about 2 s each. The whole ReceiveTimeoutSpec class: 10 passed.

[Aaronontheweb]

LGTM