#9114: Fix: Reduce NO_TIMEOUT_MS to 24 days to avoid Node.js overflow warning
agents
stale
Cluster:
Timeouts and Memory Management Fixes
## Summary
Fixes #9083 - TimeoutOverflowWarning when NO_TIMEOUT_MS exceeds 32-bit signed integer limit
## Problem
Node.js `setTimeout` uses a 32-bit signed integer internally with a maximum value of `2^31 - 1 = 2,147,483,647 ms` (≈24.8 days).
The previous `NO_TIMEOUT_MS` value of 30 days (`2,592,000,000 ms`) exceeded this limit, causing:
```
TimeoutOverflowWarning: 2592010000 does not fit into a 32-bit signed integer
```
## Solution
Reduced `NO_TIMEOUT_MS` from 30 days to 24 days (`2,073,600,000 ms`), which:
- ✅ Stays comfortably within the 32-bit signed integer limit
- ✅ Still represents effectively infinite timeout for practical purposes
- ✅ Eliminates the overflow warning
- ✅ Maintains the same behavior (used when timeout is explicitly set to 0)
## Changes
- Updated `src/agents/timeout.ts`:
- Changed constant from `30 * 24 * 60 * 60 * 1000` to `24 * 24 * 60 * 60 * 1000`
- Updated comment to explain the 32-bit limit constraint
- Added inline comment showing the actual millisecond value for clarity
## Testing
The change is purely a constant reduction with no logic changes:
- The value is still large enough to represent "no timeout" semantically
- All existing code paths remain unchanged
- No behavioral differences for any timeout values under 24 days
## Impact
- Fixes the overflow warning that appeared in logs
- Prevents potential undefined behavior when the value overflows
- No breaking changes - 24 days is still effectively infinite for agent timeouts
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This PR reduces the `NO_TIMEOUT_MS` constant used to represent an explicit “no timeout” (timeout set to `0`) in `src/agents/timeout.ts`. The value is lowered from 30 days to 24 days to stay below Node.js’s internal 32-bit signed integer limit for `setTimeout` delays, eliminating `TimeoutOverflowWarning` while keeping the same control-flow behavior for normal timeout values.
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk.
- Change is a single constant reduction with no logic/control-flow changes; new value is below Node’s 32-bit timer limit and aligns with the stated intent of avoiding TimeoutOverflowWarning.
- No files require special attention
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#11416: fix: clamp timeout values to avoid 32-bit overflow warning
by seojoonkim · 2026-02-07
86.6%
#12477: fix(agents): prevent TimeoutOverflowWarning when timeout is disabled
by skylarkoo7 · 2026-02-09
86.0%
#10636: fix: setTimeout integer overflow causing server crash
by devmangel · 2026-02-06
84.0%
#11752: fix(heartbeat): clamp setTimeout delay to 2^31-1 to prevent Timeout...
by kjaylee · 2026-02-08
79.4%
#22719: fix(agents): make subagent announce timeout configurable (restore 6...
by Valadon · 2026-02-21
75.8%
#23309: fix: remove 30-minute timeout for background exec sessions
by vksvikas · 2026-02-22
75.1%
#19414: fix: respect job timeoutSeconds for stuck runningAtMs detection
by namabile · 2026-02-17
74.4%
#18432: fix(agents): clear active run state immediately on embedded timeout
by BinHPdev · 2026-02-16
74.2%
#6302: fix: Add timeouts to prevent indefinite hangs (issues #4954, #4956,...
by batumilove · 2026-02-01
74.1%
#16342: fix(nodes-tool): use invokeTimeoutMs for HTTP timeout in invoke action
by xiaoyaner0201 · 2026-02-14
74.0%