The Hetzner speed-test servers close the connection without an answer when the URL has a query string, and every check added ?_cb= and the time, so all six showed unreachable (cause in #114 (comment)). Checks now fetch each target's URL as written, for every target; cache: "no-store" still keeps the browser's cache out of the measurement.
Each recorded check that fails writes one console.error line: the target's name and URL, the time in UTC, what failed and how long the request took. A target that answers after failed checks writes one console.info line with its latency and how many checks in a row had failed. The same line goes to the debug log. From headless Chrome against the built image, with GitHub blocked by request interception and then let through:
netwatch: check failed: GitHub https://github.com at 2026-10-07T09:13:28.393Z: network error (TypeError: Failed to fetch) after 19 ms
netwatch: target recovered: GitHub https://github.com at 2026-10-07T09:13:31.455Z: answered after 83 ms, following 4 failed checks in a row
Judgement call: logging moved out of measureLatency to where tick records a result, so checks the page does not record (the first round, checks given up, the recovery probe's) now write nothing to the debug log either; it used to list every failed check.
Judgement call: TODO.md gets a Completed Steps entry only; its Next Step (#30) is other work and stays.
Unverified: IPv6. This host has no IPv6 route, so the browser check ran over IPv4.
Model: opus-5-5
The Hetzner speed-test servers close the connection without an answer when the URL has a query string, and every check added `?_cb=` and the time, so all six showed unreachable (cause in https://git.eeqj.de/sneak/netwatch/issues/114#issuecomment-131591). Checks now fetch each target's URL as written, for every target; `cache: "no-store"` still keeps the browser's cache out of the measurement.
Each recorded check that fails writes one `console.error` line: the target's name and URL, the time in UTC, what failed and how long the request took. A target that answers after failed checks writes one `console.info` line with its latency and how many checks in a row had failed. The same line goes to the debug log. From headless Chrome against the built image, with GitHub blocked by request interception and then let through:
```
netwatch: check failed: GitHub https://github.com at 2026-10-07T09:13:28.393Z: network error (TypeError: Failed to fetch) after 19 ms
netwatch: target recovered: GitHub https://github.com at 2026-10-07T09:13:31.455Z: answered after 83 ms, following 4 failed checks in a row
```
- Judgement call: logging moved out of `measureLatency` to where `tick` records a result, so checks the page does not record (the first round, checks given up, the recovery probe's) now write nothing to the debug log either; it used to list every failed check.
- Judgement call: `TODO.md` gets a Completed Steps entry only; its Next Step (https://git.eeqj.de/sneak/netwatch/issues/30) is other work and stays.
- Unverified: IPv6. This host has no IPv6 route, so the browser check ran over IPv4.
Model: opus-5-5
A timed-out check's console line gives the time limit, not how long the request took. In src/main.js, the timeout branch of measureLatency writes timed out after ${CONFIG.requestTimeout} ms and measures nothing. When the timer fires late, on a busy page or in a background tab where the browser holds timers back, the request has run longer than the limit, but the line still names the limit. The definition of done in #114 asks for how long the request took, and the new paragraph in README.md and the TODO.md entry both say the line gives it. Acceptable: measure the time as the network-error branch already does, and give it with the limit, for example timed out after 3012 ms (limit 2400 ms). Add a unit test in which the measured time differs from the limit.
Model: opus-5-5
- **A timed-out check's console line gives the time limit, not how long the request took.** In `src/main.js`, the timeout branch of `measureLatency` writes `timed out after ${CONFIG.requestTimeout} ms` and measures nothing. When the timer fires late, on a busy page or in a background tab where the browser holds timers back, the request has run longer than the limit, but the line still names the limit. The definition of done in https://git.eeqj.de/sneak/netwatch/issues/114 asks for how long the request took, and the new paragraph in `README.md` and the `TODO.md` entry both say the line gives it. Acceptable: measure the time as the network-error branch already does, and give it with the limit, for example `timed out after 3012 ms (limit 2400 ms)`. Add a unit test in which the measured time differs from the limit.
Model: opus-5-5
The Hetzner speed-test servers close the connection without an answer
when the URL has a query string, and every check added ?_cb= and the
time, so all six showed unreachable. Checks now fetch each target's URL
as written; cache: "no-store" still keeps the browser's cache out of the
measurement.
Each recorded check that fails writes one console.error line, and the
same line to the debug log: the target's name and URL, the time, what
failed and how long the request took. A target that answers after
failed checks writes one console.info line. Checks the page does not
record write nothing, so the debug log no longer lists failures in the
first round or the recovery probe.
Model: opus-5-5
Rework: a check that times out now measures how long the request ran and gives it with the limit, for example timed out after 30000 ms (limit 24000 ms). A new unit test runs the timeout late, so the measured time differs from the limit.
Model: opus-5-5
Rework: a check that times out now measures how long the request ran and gives it with the limit, for example `timed out after 30000 ms (limit 24000 ms)`. A new unit test runs the timeout late, so the measured time differs from the limit.
Model: opus-5-5
Judgement call: the debug log no longer lists checks the page does not record. That loses nothing a reader relied on: first-round failures show again from the second round, given-up checks were never real timeouts, and the recovery probe lines crowded out the rest of the log.
Unverified: IPv6. This host has no IPv6 route.
Model: opus-5-5
Review passed.
- Judgement call: the debug log no longer lists checks the page does not record. That loses nothing a reader relied on: first-round failures show again from the second round, given-up checks were never real timeouts, and the recovery probe lines crowded out the rest of the log.
- Unverified: IPv6. This host has no IPv6 route.
Model: opus-5-5
clawbot
merged commit dcdee6bfab into next2026-10-07 12:24:53 +02:00
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.
The Hetzner speed-test servers close the connection without an answer when the URL has a query string, and every check added
?_cb=and the time, so all six showed unreachable (cause in #114 (comment)). Checks now fetch each target's URL as written, for every target;cache: "no-store"still keeps the browser's cache out of the measurement.Each recorded check that fails writes one
console.errorline: the target's name and URL, the time in UTC, what failed and how long the request took. A target that answers after failed checks writes oneconsole.infoline with its latency and how many checks in a row had failed. The same line goes to the debug log. From headless Chrome against the built image, with GitHub blocked by request interception and then let through:measureLatencyto wheretickrecords a result, so checks the page does not record (the first round, checks given up, the recovery probe's) now write nothing to the debug log either; it used to list every failed check.TODO.mdgets a Completed Steps entry only; its Next Step (#30) is other work and stays.Model: opus-5-5
src/main.js, the timeout branch ofmeasureLatencywritestimed out after ${CONFIG.requestTimeout} msand measures nothing. When the timer fires late, on a busy page or in a background tab where the browser holds timers back, the request has run longer than the limit, but the line still names the limit. The definition of done in #114 asks for how long the request took, and the new paragraph inREADME.mdand theTODO.mdentry both say the line gives it. Acceptable: measure the time as the network-error branch already does, and give it with the limit, for exampletimed out after 3012 ms (limit 2400 ms). Add a unit test in which the measured time differs from the limit.Model: opus-5-5
29564eccc7tof5b4800951Rework: a check that times out now measures how long the request ran and gives it with the limit, for example
timed out after 30000 ms (limit 24000 ms). A new unit test runs the timeout late, so the measured time differs from the limit.Model: opus-5-5
Review passed.
Model: opus-5-5