While the debug log is open, every line written to it redraws the whole panel, up to 1000 lines, and a round writes about 30 lines as its checks end. A check that ends while the page is redrawing is timed only when the page gets back to it, so its latency includes the redraw. Those latencies are shown in the rows, the summary and the health box, and sent to the backend, which stores them.
Where, on next at b1eefe0: src/main.js. append in log (lines 148 to 154) calls renderDebugLog for every line while the panel is visible; renderDebugLog (lines 1082 to 1103) rebuilds every line with replaceChildren. measureLatency reads performance.now() after await fetch (lines 557 to 566), when the page resumes it.
How to see it: run the image as "Running under upaas" says, open the page, and after a minute tick "Debug log" in the footer for half a minute, then untick it. In the image built from b1eefe0, at the default 3-second interval, the stored median latency of GitHub went from 15 ms to 79 ms with the panel open and back to 17 ms after; Cloudflare 39, 166 and 32 ms. Chrome counted 1.3 seconds of tasks over 50 ms in 10 seconds with the panel open, and none with it closed.
What is right: the page times each request (README.md, Latency measurement), and the debug log is only a panel to read (Features). Opening it must not change the latencies the page shows or reports.
Severity: medium. Every check timed while the panel is open reads too high, on the page and in the stored reports.
Definition of done
With the debug log open, writing a line no longer redraws the lines already in the panel, and the latencies shown and reported are those the page gets with the panel closed.
A unit test writes more lines than the panel keeps, with the panel open in a stand-in document, and fails if a line redraws the lines already shown.
TODO.md updated in the same commit; commit title ends (closes #N).
Model: opus-5-5
While the debug log is open, every line written to it redraws the whole panel, up to 1000 lines, and a round writes about 30 lines as its checks end. A check that ends while the page is redrawing is timed only when the page gets back to it, so its latency includes the redraw. Those latencies are shown in the rows, the summary and the health box, and sent to the backend, which stores them.
**Where**, on `next` at `b1eefe0`: `src/main.js`. `append` in `log` (lines 148 to 154) calls `renderDebugLog` for every line while the panel is visible; `renderDebugLog` (lines 1082 to 1103) rebuilds every line with `replaceChildren`. `measureLatency` reads `performance.now()` after `await fetch` (lines 557 to 566), when the page resumes it.
**How to see it**: run the image as "Running under upaas" says, open the page, and after a minute tick "Debug log" in the footer for half a minute, then untick it. In the image built from `b1eefe0`, at the default 3-second interval, the stored median latency of GitHub went from 15 ms to 79 ms with the panel open and back to 17 ms after; Cloudflare 39, 166 and 32 ms. Chrome counted 1.3 seconds of tasks over 50 ms in 10 seconds with the panel open, and none with it closed.
**What is right**: the page times each request (`README.md`, Latency measurement), and the debug log is only a panel to read (Features). Opening it must not change the latencies the page shows or reports.
**Severity**: medium. Every check timed while the panel is open reads too high, on the page and in the stored reports.
## Definition of done
- [ ] With the debug log open, writing a line no longer redraws the lines already in the panel, and the latencies shown and reported are those the page gets with the panel closed.
- [ ] A unit test writes more lines than the panel keeps, with the panel open in a stand-in document, and fails if a line redraws the lines already shown.
- [ ] `TODO.md` updated in the same commit; commit title ends ` (closes #N)`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 11:15:17 +02:00
Fixed in #135. With the debug log open, each line written is added at the end of the panel and the oldest is dropped past 1000; the whole panel is drawn only when it is opened. The panel also scrolls to its newest line once a frame rather than once a line, because scrolling it lays out every line and on its own still raised the latencies.
Model: opus-5-5
Fixed in https://git.eeqj.de/sneak/netwatch/pulls/135. With the debug log open, each line written is added at the end of the panel and the oldest is dropped past 1000; the whole panel is drawn only when it is opened. The panel also scrolls to its newest line once a frame rather than once a line, because scrolling it lays out every line and on its own still raised the latencies.
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.
While the debug log is open, every line written to it redraws the whole panel, up to 1000 lines, and a round writes about 30 lines as its checks end. A check that ends while the page is redrawing is timed only when the page gets back to it, so its latency includes the redraw. Those latencies are shown in the rows, the summary and the health box, and sent to the backend, which stores them.
Where, on
nextatb1eefe0:src/main.js.appendinlog(lines 148 to 154) callsrenderDebugLogfor every line while the panel is visible;renderDebugLog(lines 1082 to 1103) rebuilds every line withreplaceChildren.measureLatencyreadsperformance.now()afterawait fetch(lines 557 to 566), when the page resumes it.How to see it: run the image as "Running under upaas" says, open the page, and after a minute tick "Debug log" in the footer for half a minute, then untick it. In the image built from
b1eefe0, at the default 3-second interval, the stored median latency of GitHub went from 15 ms to 79 ms with the panel open and back to 17 ms after; Cloudflare 39, 166 and 32 ms. Chrome counted 1.3 seconds of tasks over 50 ms in 10 seconds with the panel open, and none with it closed.What is right: the page times each request (
README.md, Latency measurement), and the debug log is only a panel to read (Features). Opening it must not change the latencies the page shows or reports.Severity: medium. Every check timed while the panel is open reads too high, on the page and in the stored reports.
Definition of done
TODO.mdupdated in the same commit; commit title ends(closes #N).Model: opus-5-5
Fixed in #135. With the debug log open, each line written is added at the end of the panel and the oldest is dropped past 1000; the whole panel is drawn only when it is opened. The panel also scrolls to its newest line once a frame rather than once a line, because scrolling it lays out every line and on its own still raised the latencies.
Model: opus-5-5