You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@pekko.apache.org by "He-Pin (via GitHub)" <gi...@apache.org> on 2026/05/29 08:12:31 UTC

[PR] test: scale TCK Await timeouts by pekko.test.timefactor [pekko]

He-Pin opened a new pull request, #3004:
URL: https://github.com/apache/pekko/pull/3004

   ### Motivation
   
   `GroupByTest` and `PrefixAndTailTest` abort the TCK suite on JDK 25 nightly runs with:
   
   ```
   java.lang.AssertionError: Failed in iteration 18 of 100.
   Expected completion signal after signalling 10 elements (signalled 0),
   yet did not receive it within 32000 ms
     at org.reactivestreams.tck.PublisherVerification.stochastic_spec103_mustSignalOnMethodsSequentially(...)
   ```
   
   after roughly 18 iterations of `stochastic_spec103_mustSignalOnMethodsSequentially`.
   
   Both `createPublisher` implementations materialize an intermediate stream and call `Await.result(future, 3.seconds)` to obtain the `Source` wrapped by the test `Publisher`. The `3.seconds` value is a hardcoded constant that does not honour `pekko.test.timefactor`, so the JDK 25 nightly's compounded GC + ForkJoinPool pressure can push a single materialization beyond 3s during the 100-iteration stochastic test, which surfaces as a `Publisher` that signals zero elements (and then aborts the whole TCK suite).
   
   `Timeouts` already scales every other field by `timeFactor`. `publisherShutdownTimeoutMillis` is the only existing field that wasn't scaled.
   
   ### Modification
   
   - Add `Timeouts.materializerTimeoutMillis`, scaled by `timeFactor`.
   - Route the `Await.result` calls in `GroupByTest` and `PrefixAndTailTest` through the new helper instead of the hardcoded `3.seconds`.
   - Apply the same `timeFactor` scaling to the existing `publisherShutdownTimeoutMillis` so the whole `Timeouts` object behaves consistently.
   
   ### Result
   
   On local runs (`timeFactor=1`) the effective budget stays at 3s, so the test still flags genuine materialization regressions. On the JDK 25 nightly (`timeFactor=4`) the budget grows to 12s, which covers the observed worst-case materialization delays without masking real bugs.
   
   ### Tests
   
   - `sbt stream-tests-tck/Test/compile` (Scala 2.13) succeeded locally.
   
   ### References
   
   - Failing nightly: https://github.com/apache/pekko/actions/runs/26571377673
   - Failing nightly: https://github.com/apache/pekko/actions/runs/26611472055
   - Tracking issue: #2573


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org


Re: [PR] test: scale TCK Await timeouts by pekko.test.timefactor [pekko]

Posted by "He-Pin (via GitHub)" <gi...@apache.org>.
He-Pin merged PR #3004:
URL: https://github.com/apache/pekko/pull/3004


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org