openclaw - 💡(How to fix) Fix `evaluateSessionFreshness` returns fresh-forever for future `updatedAt` timestamps (clock-skew edge case) [1 comments, 2 participants]

evaluateSessionFreshness (src/config/sessions/reset-policy.ts:72-92) returns fresh: true for any session whose updatedAt is in the future relative to now, regardless of reset mode. This silently defeats both idle and daily reset gates for any caller using the result.

Code trace

// src/config/sessions/reset-policy.ts:85-86
const staleDaily = dailyResetAt != null && params.updatedAt < dailyResetAt;
const staleIdle = idleExpiresAt != null && params.now > idleExpiresAt;
// idleExpiresAt = updatedAt + idleMinutes * 60_000

For updatedAt > now:

• staleDaily is false (updatedAt is after any past dailyResetAt).
• idleExpiresAt is also in the future, so staleIdle = now > idleExpiresAt is false.
• Result: fresh: true always, no matter how far back the configured reset would otherwise sit.

Where a future updatedAt can enter the store

resolveMergedUpdatedAt (src/config/sessions/types.ts:375) takes Math.max(existing.updatedAt, patch.updatedAt, options.now ?? Date.now()), so a caller passing patch.updatedAt = <future> will persist it. Likely sources: any path feeding inbound message timestamps (clock skew between the messaging platform and the openclaw host) into the merge. Once persisted, every subsequent evaluateSessionFreshness call against that entry returns fresh.

I haven't reproduced this in a real deployment — flagging as a clock-skew edge case worth guarding rather than a confirmed prod bug. Surfaced while reviewing #72901, where the same helper is now load-bearing for the Slack thread-history fetch gate.

Possible fixes

Two shapes:

1. Clamp at evaluation time — inside evaluateSessionFreshness, treat updatedAt > now as now for staleness math. Localizes the change to the helper:

   const effectiveUpdatedAt = Math.min(params.updatedAt, params.now);
   const idleExpiresAt =
     params.policy.idleMinutes != null && params.policy.idleMinutes > 0
       ? effectiveUpdatedAt + params.policy.idleMinutes * 60_000
       : undefined;
   const staleDaily = dailyResetAt != null && effectiveUpdatedAt < dailyResetAt;

2. Reject at merge boundary — in resolveMergedUpdatedAt, drop patch.updatedAt when it exceeds options.now ?? Date.now(). Stronger guarantee but more invasive — affects any caller that legitimately needs to project forward (e.g., test fixtures).

Happy to PR option 1 if a maintainer confirms this is worth guarding.