netwatch on a 30s interval has several slow/far targets that timeout. the timeout should be 80% of the refresh interval
Definition of done:
Each target check's timeout is 80% of the current refresh interval (24 s at a 30 s interval), wherever the timeout is set today; no separate fixed timeout remains.
Changing the refresh interval changes the timeout with it, from the next round on.
A target that answers within 80% of the interval is recorded with its real time, not as a timeout; one that does not is recorded as a timeout, as today.
Rounds still never overlap: a round's checks all finish (answered or timed out) before the next round starts.
Tests cover the timeout at two different intervals.
Model: opus-5-5
sneak, 2026-09-29 in chat (verbatim):
> netwatch on a 30s interval has several slow/far targets that timeout. the timeout should be 80% of the refresh interval
Definition of done:
- Each target check's timeout is 80% of the current refresh interval (24 s at a 30 s interval), wherever the timeout is set today; no separate fixed timeout remains.
- Changing the refresh interval changes the timeout with it, from the next round on.
- A target that answers within 80% of the interval is recorded with its real time, not as a timeout; one that does not is recorded as a timeout, as today.
- Rounds still never overlap: a round's checks all finish (answered or timed out) before the next round starts.
- Tests cover the timeout at two different intervals.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 12:20:07 +02:00
Plan. The cause is in src/main.js: CONFIG.requestTimeout is Math.min(updateInterval - 100, 3000), so the timeout never exceeds 3 seconds whatever the interval; at 30 seconds a target that takes 4 seconds is recorded as a timeout.
requestTimeout becomes 80% of updateInterval, and every target check (and the latency limit that reads it) uses it; no fixed cap remains. The local-gateway probe's own 1.5-second timeout is a separate check of which address answers, not a target check; say in the PR if it stays.
The timeout follows the interval selector from the next round on.
Rounds never overlap: check how a round is started today and keep it so the next round starts only after the current one's checks have all finished or timed out.
Tests at two intervals, using Node's built-in test runner so no dependency is added, run from script/frontend-test and so from make check.
Verified in a headless browser in a container: at a 30-second interval, a target that answers in several seconds is recorded with its real time.
Model: opus-5-5
Plan. The cause is in `src/main.js`: `CONFIG.requestTimeout` is `Math.min(updateInterval - 100, 3000)`, so the timeout never exceeds 3 seconds whatever the interval; at 30 seconds a target that takes 4 seconds is recorded as a timeout.
1. `requestTimeout` becomes 80% of `updateInterval`, and every target check (and the latency limit that reads it) uses it; no fixed cap remains. The local-gateway probe's own 1.5-second timeout is a separate check of which address answers, not a target check; say in the PR if it stays.
2. The timeout follows the interval selector from the next round on.
3. Rounds never overlap: check how a round is started today and keep it so the next round starts only after the current one's checks have all finished or timed out.
4. Tests at two intervals, using Node's built-in test runner so no dependency is added, run from `script/frontend-test` and so from `make check`.
5. Verified in a headless browser in a container: at a 30-second interval, a target that answers in several seconds is recorded with its real time.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sneak, 2026-09-29 in chat (verbatim):
Definition of done:
Model: opus-5-5
Plan. The cause is in
src/main.js:CONFIG.requestTimeoutisMath.min(updateInterval - 100, 3000), so the timeout never exceeds 3 seconds whatever the interval; at 30 seconds a target that takes 4 seconds is recorded as a timeout.requestTimeoutbecomes 80% ofupdateInterval, and every target check (and the latency limit that reads it) uses it; no fixed cap remains. The local-gateway probe's own 1.5-second timeout is a separate check of which address answers, not a target check; say in the PR if it stays.script/frontend-testand so frommake check.Model: opus-5-5