Initialize schedule lazily #801
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
Previously, we have initialized the schedule eagerly when it was created. Among the state of the schedule is the point in time when it was started. However, as the schedule is not immediately executed after creation, it is possible that the start timestamp is slightly off. This is usually not a problem in practice but may cause test failures where we use very short-lived schedules (one second in total). With this commit we wrap the schedule (which is a generator) in a handle. This handle is passed to the executor which can then lazily initialize the schedule so the timestamp matches exactly the point in time when the schedule is executed. Closes elastic#600
danielmitterdorfer
added
bug
|
Thanks! |
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.
Previously, we have initialized the schedule eagerly when it was
created. Among the state of the schedule is the point in time when it
was started. However, as the schedule is not immediately executed after
creation, it is possible that the start timestamp is slightly off. This
is usually not a problem in practice but may cause test failures where
we use very short-lived schedules (one second in total).
With this commit we wrap the schedule (which is a generator) in a
handle. This handle is passed to the executor which can then lazily
initialize the schedule so the timestamp matches exactly the point in
time when the schedule is executed.
Closes #600