JobSnooze ignores Config.Test.Time when calculating scheduled_at

[pablobaldez]

Description

Config.Test.Time was introduced in #754 (following #751) to let tests provide a synthetic rivertype.TimeGenerator. Scheduled-job eligibility uses that configured time source, but JobSnooze calculates its next absolute timestamp from the process wall clock:

nextAttemptScheduledAt := time.Now().Add(snoozeErr.Duration)

The executor then compares that wall-clock-derived timestamp with e.Time.Now(). When Config.Test.Time is intentionally ahead of or behind wall time, the two values belong to different timelines.

This is present in v0.39.0 and still appears on master.

Example

Assume:

• process wall clock: 2026-07-22 12:00 UTC
• Config.Test.Time: 2026-06-10 12:00 UTC
• worker returns river.JobSnooze(8 * time.Hour)

The current implementation stores approximately:

scheduled_at = 2026-07-22 20:00 UTC

The expected synthetic-time value is:

scheduled_at = 2026-06-10 20:00 UTC

Advancing the synthetic clock by eight hours therefore does not make the job eligible; it remains scheduled until the wall-clock-derived timestamp. If the synthetic clock is ahead of wall time, the inverse can happen and the snoozed job may become immediately eligible.

This makes Config.Test.Time unreliable for behavioral or manual simulation tests that exercise workers which repeatedly snooze themselves.

Suggested change

Use the executor's configured time generator when calculating the snooze target:

- nextAttemptScheduledAt := time.Now().Add(snoozeErr.Duration)
+ nextAttemptScheduledAt := e.Time.Now().Add(snoozeErr.Duration)

This is also consistent with the comparison immediately below, which already uses e.Time.Now().

When Config.Test.Time is nil, River's default time generator still delegates to time.Now(), so ordinary runtime behavior should remain unchanged.

Suggested regression test

Create a client/worker with Config.Test.Time fixed to an instant that differs materially from wall time, return JobSnooze(duration), and assert that the resulting job's ScheduledAt equals the synthetic instant plus the snooze duration.

[pablobaldez]

I found a second scheduling inconsistency related to Config.Test.Time while integrating a logical clock with River v0.39.0.

The configured time generator is installed as the client's archetype time and is used by the job executor and scheduler. However, the default retry policy still derives retry timestamps directly from the process wall clock:

• DefaultClientRetryPolicy.NextRetry calls time.Now().UTC() through timeNowUTC.
• The executor compares that result with e.Time.Now().
• The scheduler later evaluates the resulting scheduled_at using the configured time generator.

This mixes two clocks in one retry flow.

For example, if the configured logical time is behind wall time, a failed job can be scheduled far into the logical future and never become eligible during the scenario. If logical time is ahead of wall time, the retry timestamp is already in the past; the executor falls back to the same wall-clock default policy and may make the job immediately available.

Relevant code in v0.39.0:

• default retry policy uses wall time
• job executor compares the retry timestamp with its configured time
• job scheduler uses its configured time

Expected behavior: retry timestamps produced by River's default policy should use the same configured time generator used to evaluate their eligibility, so setting Config.Test.Time keeps the complete scheduling path on one coherent clock.

This is separate from the JobSnooze implementation, but it exposes the same broader problem: Config.Test.Time is not applied consistently to scheduling-related timestamps. If you prefer, I can split this into a separate issue.

[brandur]

@pablobaldez Is there a practical situation where this has mattered for some reason? The use of time generator isn't fully guaranteed throughout River's codebase everywhere. We basically use it in some situations where it's useful to stub a wall clock for a specific test (and it's been sprinkled pretty liberally throughout other code too), but there's lots of code that doesn't use it.

[pablobaldez]

@brandur Yes I do. We use River in a local environment for manual application testing, where testers can advance a logical clock.
A job may finish successfully and return JobSnooze(8 * time.Hour). The tester then advances the logical clock by eight hours and expects the job to run again.
Currently, JobSnooze calculates scheduled_at from wall time, while job eligibility is checked against Config.Test.Time. If logical time differs from wall time, advancing it by eight hours does not make the job eligible.
We do not need Config.Test.Time to replace every timer in River. We only need the same scheduling flow to use one clock when creating and later evaluating scheduled_at.
I can submit a small PR with the change if that would help.

[brandur]

@pablobaldez Sure, I'll take a look at a PR. Adding a few more uses of the time generator should generally not be a problem.