Changes ScheduledMessage.RecalculateStartAfter() logic to advance StartAfter until it moves past the current date
A side effect of the implementation is that all StartAfter times are expected to be UTC
Changes Scheduler.LoadState to call RecalculateStartAfter() on loaded schedules whose StartAfter is before the current time
Adds hidden parameterless constructor for Logger, to enable some mocking
There's probably a better way to do that--I'm not real familiar with PowerShell's testing and mocking libraries
Related Issue
120
Motivation and Context
If a command was originally scheduled several months ago and the bot is restarted, a very large number of executions will occur very quickly. Depending on the command scheduled, this may prove problematic.
How Has This Been Tested?
Added unit tests to ScheduledMessages.tests.ps1 to check the behavior of RecalculateStartAfter() with dates in the future and the past.
Added unit tests (and some hacky mocks) in Scheduler.tests.ps1 to check the behavior of Scheduler.LoadState() when a schedule with a StartAfter in the past is loaded.
Manually started a bot and ran !newschedule --command 'help' --interval minutes --value 5 --startafter '2018-10-01 12:25pm' and verified that only one response was produced immediately. Restarted the bot and verified that no responses were produced on schedule load.
Screenshots (if appropriate):
Types of changes
[x ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[x ] My code follows the code style of this project.
I think? I don't do a lot in PowerShell on a day-to-day basis, so I may have inadvertently missed something.
[ ] My change requires a change to the documentation.
Description
ScheduledMessage.RecalculateStartAfter()
logic to advanceStartAfter
until it moves past the current dateStartAfter
times are expected to be UTCScheduler.LoadState
to callRecalculateStartAfter()
on loaded schedules whoseStartAfter
is before the current timehidden
parameterless constructor forLogger
, to enable some mockingRelated Issue
120
Motivation and Context
If a command was originally scheduled several months ago and the bot is restarted, a very large number of executions will occur very quickly. Depending on the command scheduled, this may prove problematic.
How Has This Been Tested?
Added unit tests to
ScheduledMessages.tests.ps1
to check the behavior ofRecalculateStartAfter()
with dates in the future and the past.Added unit tests (and some hacky mocks) in
Scheduler.tests.ps1
to check the behavior ofScheduler.LoadState()
when a schedule with aStartAfter
in the past is loaded.Manually started a bot and ran
!newschedule --command 'help' --interval minutes --value 5 --startafter '2018-10-01 12:25pm'
and verified that only one response was produced immediately. Restarted the bot and verified that no responses were produced on schedule load.Screenshots (if appropriate):
Types of changes
Checklist: