Each target check now times out after 80% of the refresh interval, 24 seconds at 30 seconds, where it was capped at 3 seconds, which recorded slow, far targets as timeouts. The recovery probe's checks use the same timeout; an interval change takes effect from the next round.
Rounds never overlap: at a steady interval the 20% margin ensures it, and a round asked for while the last one's checks are still waiting, after an interval change or by the recovery probe, is now skipped.
What the diff does not show:
After an interval change mid-round, the first round at the new interval waits for that round's checks, at most 80% of the old interval.
index.html now links src/styles.css, which src/main.js imported: the unit tests import src/main.js in Node, which cannot import CSS. The built stylesheet is unchanged.
The unit tests use Node's built-in test runner, adding no dependency; script/frontend-test runs them before the build.
In headless Chrome at a 30-second interval, a target answering after 5 seconds was recorded with its real time, one answering after 26 seconds as a timeout, and no round started before the last one's checks had all finished, also across an interval change mid-round.
Judgement call: the recovery probe, which starts checks every half second, starts no new ones while its last ones wait; with 24-second timeouts they would pile up during an outage.
The local-gateway detection keeps its 1.5-second timeout: it picks which address answers and is not a target check.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/netwatch/issues/78.
Each target check now times out after 80% of the refresh interval, 24 seconds at 30 seconds, where it was capped at 3 seconds, which recorded slow, far targets as timeouts. The recovery probe's checks use the same timeout; an interval change takes effect from the next round.
Rounds never overlap: at a steady interval the 20% margin ensures it, and a round asked for while the last one's checks are still waiting, after an interval change or by the recovery probe, is now skipped.
What the diff does not show:
- After an interval change mid-round, the first round at the new interval waits for that round's checks, at most 80% of the old interval.
- `index.html` now links `src/styles.css`, which `src/main.js` imported: the unit tests import `src/main.js` in Node, which cannot import CSS. The built stylesheet is unchanged.
- The unit tests use Node's built-in test runner, adding no dependency; `script/frontend-test` runs them before the build.
In headless Chrome at a 30-second interval, a target answering after 5 seconds was recorded with its real time, one answering after 26 seconds as a timeout, and no round started before the last one's checks had all finished, also across an interval change mid-round.
- Judgement call: the recovery probe, which starts checks every half second, starts no new ones while its last ones wait; with 24-second timeouts they would pile up during an outage.
- The local-gateway detection keeps its 1.5-second timeout: it picks which address answers and is not a target check.
Model: opus-5-5
Each target check now times out after 80% of the refresh interval, 24
seconds at 30 seconds, where it was capped at 3 seconds, so slow, far
targets are recorded with their real time. A round asked for while the
last one's checks are still waiting, after an interval change or by the
recovery probe, is skipped, so rounds never overlap; the recovery probe
starts no new checks while its last ones wait.
The frontend has its first unit tests, run by script/frontend-test with
Node's built-in test runner. index.html now links src/styles.css, which
src/main.js imported, since Node cannot import CSS.
Model: opus-5-5
Recovery after an outage is now shown up to about 80% of the interval late (src/main.js, startRecoveryProbe and doTick). When an outage makes checks hang rather than fail at once, the recovery probe starts new checks only after its last ones time out (every 24 seconds at a 30-second interval, not every half second), and the round it asks for once a target answers is skipped whenever a round is waiting, which in such an outage is 24 of every 30 seconds; that round then ends in timeouts and the page stays OFFLINE. At a 30-second interval the page showed the recovery 20 to 24 seconds after the targets answered again, where next shows it within about a second. Acceptable: recovery shown about as promptly as on next at any interval, with rounds still never overlapping and the probe's checks not piling up. For example, the probe keeps trying every half second and gives up its previous checks when it starts new ones, and when it finds a target answering while a round is waiting, that round's checks are abandoned and a new round starts at once. The comment above startRecoveryProbe and the README.md text must match what it then does.
The unit tests do not catch the reported bug where it takes effect (test/unit/main.test.js). They check the value of CONFIG.requestTimeout and a 600 ms target at 500 ms and 1500 ms intervals, so capping either the abort in measureLatency or CONFIG.maxLatency at 3 seconds leaves both tests passing, though either brings back the reported bug at a 30-second interval; removing the abort altogether passes too. Acceptable: tests that fail on each of those changes, for example a check slower than 3 seconds but within 80% of the interval recorded with its real time, and a check that never answers recorded as a timeout at 80% of the interval, within the time make test allows.
Model: opus-5-5
1. Recovery after an outage is now shown up to about 80% of the interval late (`src/main.js`, `startRecoveryProbe` and `doTick`). When an outage makes checks hang rather than fail at once, the recovery probe starts new checks only after its last ones time out (every 24 seconds at a 30-second interval, not every half second), and the round it asks for once a target answers is skipped whenever a round is waiting, which in such an outage is 24 of every 30 seconds; that round then ends in timeouts and the page stays OFFLINE. At a 30-second interval the page showed the recovery 20 to 24 seconds after the targets answered again, where `next` shows it within about a second. Acceptable: recovery shown about as promptly as on `next` at any interval, with rounds still never overlapping and the probe's checks not piling up. For example, the probe keeps trying every half second and gives up its previous checks when it starts new ones, and when it finds a target answering while a round is waiting, that round's checks are abandoned and a new round starts at once. The comment above `startRecoveryProbe` and the `README.md` text must match what it then does.
2. The unit tests do not catch the reported bug where it takes effect (`test/unit/main.test.js`). They check the value of `CONFIG.requestTimeout` and a 600 ms target at 500 ms and 1500 ms intervals, so capping either the abort in `measureLatency` or `CONFIG.maxLatency` at 3 seconds leaves both tests passing, though either brings back the reported bug at a 30-second interval; removing the abort altogether passes too. Acceptable: tests that fail on each of those changes, for example a check slower than 3 seconds but within 80% of the interval recorded with its real time, and a check that never answers recorded as a timeout at 80% of the interval, within the time `make test` allows.
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.
Closes #78.
Each target check now times out after 80% of the refresh interval, 24 seconds at 30 seconds, where it was capped at 3 seconds, which recorded slow, far targets as timeouts. The recovery probe's checks use the same timeout; an interval change takes effect from the next round.
Rounds never overlap: at a steady interval the 20% margin ensures it, and a round asked for while the last one's checks are still waiting, after an interval change or by the recovery probe, is now skipped.
What the diff does not show:
index.htmlnow linkssrc/styles.css, whichsrc/main.jsimported: the unit tests importsrc/main.jsin Node, which cannot import CSS. The built stylesheet is unchanged.script/frontend-testruns them before the build.In headless Chrome at a 30-second interval, a target answering after 5 seconds was recorded with its real time, one answering after 26 seconds as a timeout, and no round started before the last one's checks had all finished, also across an interval change mid-round.
Model: opus-5-5
Recovery after an outage is now shown up to about 80% of the interval late (
src/main.js,startRecoveryProbeanddoTick). When an outage makes checks hang rather than fail at once, the recovery probe starts new checks only after its last ones time out (every 24 seconds at a 30-second interval, not every half second), and the round it asks for once a target answers is skipped whenever a round is waiting, which in such an outage is 24 of every 30 seconds; that round then ends in timeouts and the page stays OFFLINE. At a 30-second interval the page showed the recovery 20 to 24 seconds after the targets answered again, wherenextshows it within about a second. Acceptable: recovery shown about as promptly as onnextat any interval, with rounds still never overlapping and the probe's checks not piling up. For example, the probe keeps trying every half second and gives up its previous checks when it starts new ones, and when it finds a target answering while a round is waiting, that round's checks are abandoned and a new round starts at once. The comment abovestartRecoveryProbeand theREADME.mdtext must match what it then does.The unit tests do not catch the reported bug where it takes effect (
test/unit/main.test.js). They check the value ofCONFIG.requestTimeoutand a 600 ms target at 500 ms and 1500 ms intervals, so capping either the abort inmeasureLatencyorCONFIG.maxLatencyat 3 seconds leaves both tests passing, though either brings back the reported bug at a 30-second interval; removing the abort altogether passes too. Acceptable: tests that fail on each of those changes, for example a check slower than 3 seconds but within 80% of the interval recorded with its real time, and a check that never answers recorded as a timeout at 80% of the interval, within the timemake testallows.Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.