Fix M5 feedback: bound cleanup interval to prevent overflow

[Jasonnnz]

Clamps cleanupIntervalMs to 2^31-1 ms before passing to setInterval to prevent near-continuous execution from timer overflow. Part of #6899.

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🟡 Log message reports original intervalMs instead of clamped safeInterval

When startRecordingCleanup is called with an intervalMs value exceeding 2^31-1, the runtime clamp on line 81 correctly limits the actual interval passed to setInterval. However, the log message on line 93 still reports the original unclamped intervalMs value, misleading operators into thinking the timer is running at the requested (overflowing) interval.

Detailed Explanation

On line 81, safeInterval is computed as Math.min(intervalMs, MAX_INTERVAL_MS), and this clamped value is correctly passed to setInterval on line 89. But the log on line 93 logs { intervalMs } — the original parameter — not the actual value used:

log.info({ intervalMs }, 'Recording cleanup worker started');

If clamping occurs, the log would say e.g. intervalMs: 3000000000 while the real interval is 2147483647. This makes debugging timer behavior harder.

In practice, the schema validation (.max(2_147_483_647) at assistant/src/config/schema.ts:1067) prevents out-of-range values from reaching this code path via config, so this only affects direct callers bypassing config validation.

Impact: Misleading log output when clamping is triggered; low practical impact given schema validation.

(Refers to line 93)

---

Was this helpful? React with 👍 or 👎 to provide feedback.