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.
devblackops
commented
6 years ago
Description
ScheduledMessage.RecalculateStartAfter()logic to advanceStartAfteruntil it moves past the current dateStartAftertimes are expected to be UTCScheduler.LoadStateto callRecalculateStartAfter()on loaded schedules whoseStartAfteris before the current timehiddenparameterless 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.ps1to check the behavior ofRecalculateStartAfter()with dates in the future and the past.Added unit tests (and some hacky mocks) in
Scheduler.tests.ps1to check the behavior ofScheduler.LoadState()when a schedule with aStartAfterin 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: