The GitHub Actions job "Binary Compatibility" on pekko.git/flasky_java21 has 
succeeded.
Run started by GitHub user He-Pin (triggered by He-Pin).

Head commit for run:
7f04fcbe198b2c0d0a309549a59cedefdda154ea / He-Pin <[email protected]>
chore: fix flasky test in MetricsBasedResizerSpec

Fix Summary
**Problem:** The test case "must update the underutilizationStreak 
highestUtilization if current utilization is higher" within 
`MetricsBasedResizerSpec` was failing intermittently on CI; the expected 
`highestUtilization` value was 2, but the actual value was 1.

**Root Cause:** A race condition. The test sends one message each to `routee 0` 
and `routee 1`, followed by an `await` call; however, the `await` only 
guarantees that the actors have *begun* processing the messages (specifically, 
that `first.countDown()` has been invoked). When `reportMessageCount` checks 
`cell.currentMessage` and `mailbox.numberOfMessages`, a very brief time window 
may exist—particularly under the high load conditions of the CI 
environment—during which a specific routee's message count appears to be 0. 
This leads to the `utilized` metric being calculated as 1 instead of the 
correct value of 2.

**Fix:** After the initial `mockSend(await = true)` calls, an additional 
`mockSend(await = false)` message is now sent to both `routee 0` and `routee 
1`. This ensures that, even if the `currentMessage` state is momentarily 
indeterminate, there remain pending messages within the mailbox (i.e., 
`numberOfMessages > 0`), thereby guaranteeing the correct calculation of the 
`utilized` metric. This approach aligns with the pattern utilized by other 
tests within the same test file (e.g., the test for "record last 
totalQueueLength correctly").

Report URL: https://github.com/apache/pekko/actions/runs/23401209606

With regards,
GitHub Actions via GitBox


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to