Repository navigation
Setting the system clock backwards silently stops the action for that long (interval timed with wall-clock DateTimeOffset.Now) #54
Description
Activity
Triage
- Category: Bug
- Priority: Medium. After a backwards wall-clock change, the action silently stops running for the size of the change. Such changes are rare (NTP step, manual change, VM resume), but the resulting outage is hard to diagnose.
- Area / suggested assignee: The scheduling check in the polling loop (
IntervalAction.cs:228-246). Maintainer: @matt-edmondson. - Duplicates: None. It is related to Restart right after Stop leaves the old polling loop alive, so two loops run the action at double rate and can overlap it #52 (restart after stop leaves two loops running) and Non-positive or infinite PollingInterval silently kills the loop or makes Restart()/Stop() hang forever #53 (non-positive or infinite
PollingInterval). All three touch the same polling loop, so fixing them together, or at least in sequence, avoids conflicts. - In progress: No open PR.
Next steps: Drive scheduling from
TimeProvider.GetTimestamp()/GetElapsedTime(), usingMicrosoft.Bcl.TimeProvideron older TFMs. This gives a monotonic clock, and tests can inject aFakeTimeProviderthat jumps the wall clock backwards. KeepLastRunTimeas a wall-clock value for display only.
Generated by Claude Code
What's wrong
The polling loop decides whether to run with this check (
IntervalAction/IntervalAction.cs:228):LastRunTimeis set fromDateTimeOffset.Now(lines 236 and 246). Wall-clock time is not monotonic: NTP corrections, manual clock changes and VM resume can all move it backwards.Failure scenario
ActionInterval = 1s, and the action has just run.Now - LastRunTimeis now about −1h, which is never> 1s. The action does not run for about an hour, and nothing is thrown or logged.A forward jump has the opposite effect: one run happens early. DST changes are not affected, because
DateTimeOffsetcompares UTC instants; only real system clock changes are.Why it matters
The library exists to run an action every N seconds, for example polling, heartbeats or autosave. A long silent gap after a clock sync is a hard-to-diagnose outage.
Suggested fix
Time intervals with a monotonic source: store
Stopwatch.GetTimestamp()(orEnvironment.TickCount64) for the last run and compare elapsed ticks againstActionInterval.LastRunTimecan remain as a wall-clock value for display if it is part of the public surface. It just shouldn't drive scheduling.Acceptance criteria
The scheduling decision no longer depends on
DateTimeOffset.Now. A test that injects a clock (or the monotonic abstraction, e.g.TimeProvider) shows that a backwards wall-clock jump does not delay the next run.