442
}
443
444
>
func (s *scheduler) now() time.Time {
workflow.go
445
>
// Notes:
446
>
// 1. The time returned here is actually the timestamp of the WorkflowTaskStarted
447
>
// event, which is generated in history, not any time on the worker itself.
448
>
// 2. There will be some delay between when history stamps the time on the
449
>
// WorkflowTaskStarted event and when this code runs, as the event+task goes through
450
>
// matching and frontend. But it should be well under a second, which is our minimum
451
>
// granularity anyway.
452
>
// 3. It's actually the maximum of all of those events: the go sdk enforces that
453
>
// workflow time is monotonic. So if the clock on a history node is wrong and workflow
454
>
// time is ahead of real time for a while, and then goes back, scheduled jobs will run
455
>
// ahead of time, and then nothing will happen until real time catches up to where it
456
>
// was temporarily ahead. Currently the only way to "recover" from this situation is
457
>
// to recreate the schedule/scheduler workflow.
458
>
// 4. Actually there is one way time can appear to go backwards from the point of view
459
>
// of this workflow: across a continue-as-new, since monotonicity isn't preserved
460
>
// there (as far as I know). We'll treat that the same since we keep track of the last
461
>
// processed schedule time.
462
>
return workflow.Now(s.ctx)
463
>
}
464
465
func (s *scheduler) processPatch(patch *schedulepb.SchedulePatch) {