Optionally allow first_at to be set in the past #342
Merged
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.
First off - thanks for creating and maintaining this great library, my team has been using it for many years. However, one thing that has consistently plagued us throughout the years is the
ArgumentError
thrown iffirst_at
is in the past. We userufus-scheduler
viaresque-scheduler
, and unfortunately we have seen wildly inconsistent performance when saving new schedules (sometimes up to 2 minutes between when we save and when rufus processes the schedule). Because of this, even if we pass in afirst_at
in the future, when rufus processes the job it is no longer in the future and throws an error and crashes the scheduler. As a workaround, we have had to add in an an artificial buffer that if our desiredfirst_at
is less than 2 minutes from now, set it to nil instead so rufus does not throw an error.However, this behavior isn't entirely desirable since it can skew the execution time of our schedules. We'd much prefer to not to have to handle the buffer on our side, and pass in an option which will accept a first_at in the past and set it to
:now
if it is.Would you be open to allowing this option? This would GREATLY help us. The amount of time we have spent implementing various workarounds is truly inconceivable.
Note: Ruby is not one of my most proficient languages so apologies in advance. Feel free to edit/change as needed.