TimerTrigger can miss IsPastDue

[brettsam]

Investigating this issue: http://stackoverflow.com/questions/42386299/azure-function-on-time-trigger-not-firing

The scenario I'm seeing:

Time	Message
2017-02-21 00:59:11.4454545	Function 'Host.Functions.UpdateData' initial status: Last='0001-01-01T00:00:00.0000000', Next='2017-02-21T01:00:00.0000000+00:00'
2017-02-21 00:59:11.4454758	The next 5 occurrences of the schedule will be: 2/21/2017 1:00:00 AM, etc

... then a quick restart and:

Time	Message
2017-02-21 01:00:12.0984654	Function 'Host.Functions.UpdateData' initial status: Last='0001-01-01T00:00:00.0000000', Next='2017-02-21T01:00:00.0000000+00:00'
2017-02-21 01:00:12.1164413	The next 5 occurrences of the schedule will be: 2/22/2017 1:00:00 AM, etc

I think this logic is flawed: https://github.com/Azure/azure-webjobs-sdk-extensions/blob/dev/src/WebJobs.Extensions/Extensions/Timers/Scheduling/ScheduleMonitor.cs#L67-L72

In this case, b/c now is slightly past the execution time, we're re-calculating it and ignoring the stored Next value. I believe if there's a stored Next, we should take that into account. We'll need to look through the tests and see what scenario the current logic is enabling before tweaking anything.

[brettsam]

This test looks flawed: https://github.com/Azure/azure-webjobs-sdk-extensions/blob/dev/test/WebJobs.Extensions.Tests/Extensions/Timers/Scheduling/FileSystemScheduleMonitorTests.cs#L159-L196

Because the schedule is mocked, it's returning GetNextOccurence() times in the past, which gives us the 'past due' calculation that we expect. In reality, that will never happen.

I believe we check for a 'never run' function is because we don't want to rely on the stored Next value. If someone has changed the schedule since that was stored, then the Next value is invalid and we need to re-calculate it.

I'm thinking that storing an LastUpdated value along with the Next and Last values would give us all the details we want. Then we could check whether the calculation from that time has changed -- if it has, we know the schedule has changed. This needs to work with existing stored schedules, though.

@mathewc -- I think I understand where the logic is coming from -- any other ideas?

[weiyin02]

hi Brettsan, this is exactly what we encountered. we want to re-schedule as soon as published new version, and also not to run same function at the same time by different schedule which is past or new.
from above communication, sorry, I didn't understand what is solution?
thank you,