[Backport stable/8.0] Unflake timer start event test #10893
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pretty much all timer start event tests increase the engine time to test the timer scheduling. These tests can all suffer from unwanted race conditions becaue the timer is scheduled in a post-commit task. There is no clear way to await for this post-commit task to be executed, except for awaiting the engine to reach the end of the log. Since we generally only want to time travel in tests when there is something related to the timer scheduling, it makes sense to hide this in the `increaseTime` method of the EngineRule. Also note that this only matters when the streamprocessor is currently processing. If the engine is paused, the hasReachedEnd method cannot be called because the relevant actor is also paused. Co-authored-by: Remco Westerhoud <remco@westerhoud.nl> Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com> (cherry picked from commit 6efebfb)
If you want to increase the time, we're now using the streamprocessor directly. But in the shouldAvoidTriggeringMultipleTimes test case, the engine was stopped before increasing the time. When the engine is stopped, the stream processor is removed. However, this test just wants to verify wht happens if the scheduled timer triggers and the upcoming due date would also be in the past. That can be achieved as well by pausing the engine instead of stopping it completely. Note that when the engine is paused, we don't have to reset the recording exporter (on restart it would re-export all records again). Co-authored-by: Remco Westerhoud <remco@westerhoud.nl> Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com> (cherry picked from commit c88c9cb)
Co-authored-by: Remco Westerhoud <remco@westerhoud.nl> Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com> (cherry picked from commit 9d51bfd)
Now that the EngineRule.increaseTime can guarantee that timers are scheduled before time traveling, we no longer need Awaitility to repeatedly check that the timer triggered. Co-authored-by: Remco Westerhoud <remco@westerhoud.nl> Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com> (cherry picked from commit 893f5d5)
This test was flawed as it creates a timer with a duration of 100ms. Then it continues to verify it has been triggered after 1 second. This worked because the engine increased it's time. This happened before the timer was scheduled so in reality the timer would trigger after 1.1 seconds. With the change in the increase time method to wait until the engine is idle before increasing the time this broke, as the timer would now be scheduled for the 100ms mark as expected. (cherry picked from commit 5c467e4)
remcowesterhoud
approved these changes
Nov 2, 2022
|
Build succeeded: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Backport of #10867 to
stable/8.0.relates to #10272
Reviewer, I had to resolve a few conflicts: