Refactor eventually to ensure wall-clock time usage#5705
Conversation
…e timeout exceptions Fixes #5147
…ns for clarity, and add tests
|
@OliverO2 I want to be conscious of your users who might be using Kotest's assertions library. Is there anything in this that would give you concern? Essentially, updating eventually to check for TestDispatcher and if virtual time is present, then using a wall clock implementation (that I think you derived actually), since eventually using virtual time makes no sense. |
…n CI The default PRODUCT_NAME was set to IC-261 which caused gradle-check CI jobs (which don't set PRODUCT_NAME) to compile the IntelliJ plugin against the IC-261 EAP snapshot. That EAP bundles Kotlin with metadata version 2.4.0, which is incompatible with the project's Kotlin 2.2.x compiler. Revert the default to IC-253 so that CI gradle-check jobs build against the stable 2025.3 platform. The dedicated IC-261 workflow jobs set PRODUCT_NAME explicitly and override the Kotlin version to 2.3.10. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ibs.versions.toml`
|
Thanks for pinging! Ensuring real time for So all is good! Another question is whether it would make sense at all to use real-time |
…6 in WASM Gradle scripts
…` in Gradle script
Now eventually will detect virtual time and flip onto a wall-clock time instead.
Fixes #5147