README.md line 237 (Report storage), at v1.0.0-rc1: while report files cannot be written, "POST /api/v1/reports refuses every report with 500 and keeps nothing of it, so the page keeps its samples and sends them again at its next report." Lines 155 to 156 (Reporting): "Delivery failure is quiet — one debug-log line per outage, retried at the next interval, never blocking probing." Neither sentence says that the unsent samples live only in the 100-entry history (web/src/main.js lines 15 to 19 and 330 to 333) and fall out of it, which is what happens:
At the 1 s interval the history spans 100 s and reports go every 60 s. One refused, failed or abandoned report means the next delivery comes 120 s after the last one, and the oldest 20 s of samples per host are already gone: one failure loses 20 samples from each of the 27 hosts. At 2 s it takes three refusals in a row, at 3 s five.
Reporter.flush (line 531) sends nothing while paused, but paused rounds push markers into the same history (line 304). A pause longer than the history window (100 s at 1 s, 5 minutes at 3 s) drops every sample recorded before it that no report had delivered: up to one report interval of samples per host.
The dropping itself is on record (#53: unsent samples are bounded by the history window, oldest dropped first); the README's sentences promise more than that, and the 1 s case, where one failure already loses data, is stated nowhere.
How to see it: unit test: CONFIG.updateInterval = 1000, push 120 samples with t = n * 1000 into a host, make fetch reject once, then resolve; the second flush sends samples from t = 21000 on, not from t = 1000.
What is right: either the README states the bound (what one refused report loses at each interval, and what a long pause loses), or the reporter keeps unreported samples out of the trim, as clearedHistory already does for an interval change, so the sentences become true. Which, is sneak's call.
Severity: low. Bounded telemetry loss, only while the backend refuses reports or the page is paused for longer than its history.
Definition of done
sneak's choice is recorded on this issue: document the bound, or keep unreported samples until they are delivered (with a bound of their own, stated).
README.md Reporting and Report storage say what is kept and what is lost, in both cases; if the reporter changes, a unit test covers the 1 s case above and the pause case.
TODO.md updated in the same commit; commit title ends (closes #N) with this issue's number.
Model: fable-5-1
`README.md` line 237 (Report storage), at `v1.0.0-rc1`: while report files cannot be written, "`POST /api/v1/reports` refuses every report with 500 and keeps nothing of it, so the page keeps its samples and sends them again at its next report." Lines 155 to 156 (Reporting): "Delivery failure is quiet — one debug-log line per outage, retried at the next interval, never blocking probing." Neither sentence says that the unsent samples live only in the 100-entry history (`web/src/main.js` lines 15 to 19 and 330 to 333) and fall out of it, which is what happens:
- At the 1 s interval the history spans 100 s and reports go every 60 s. One refused, failed or abandoned report means the next delivery comes 120 s after the last one, and the oldest 20 s of samples per host are already gone: one failure loses 20 samples from each of the 27 hosts. At 2 s it takes three refusals in a row, at 3 s five.
- `Reporter.flush` (line 531) sends nothing while paused, but paused rounds push markers into the same history (line 304). A pause longer than the history window (100 s at 1 s, 5 minutes at 3 s) drops every sample recorded before it that no report had delivered: up to one report interval of samples per host.
The dropping itself is on record (https://git.eeqj.de/sneak/netwatch/issues/53: unsent samples are bounded by the history window, oldest dropped first); the README's sentences promise more than that, and the 1 s case, where one failure already loses data, is stated nowhere.
**How to see it**: unit test: `CONFIG.updateInterval = 1000`, push 120 samples with `t = n * 1000` into a host, make `fetch` reject once, then resolve; the second `flush` sends samples from `t = 21000` on, not from `t = 1000`.
**What is right**: either the README states the bound (what one refused report loses at each interval, and what a long pause loses), or the reporter keeps unreported samples out of the trim, as `clearedHistory` already does for an interval change, so the sentences become true. Which, is sneak's call.
**Severity**: low. Bounded telemetry loss, only while the backend refuses reports or the page is paused for longer than its history.
## Definition of done
- [ ] sneak's choice is recorded on this issue: document the bound, or keep unreported samples until they are delivered (with a bound of their own, stated).
- [ ] `README.md` Reporting and Report storage say what is kept and what is lost, in both cases; if the reporter changes, a unit test covers the 1 s case above and the pause case.
- [ ] `TODO.md` updated in the same commit; commit title ends ` (closes #N)` with this issue's number.
Model: fable-5-1
clawbot
self-assigned this 2026-10-14 16:08:46 +02:00
Decided from the record rather than asked: #53 already settled that unsent samples are bounded by the history window, oldest dropped first, so the reporter stays as it is and README.md Reporting and Report storage state that bound: what one refused or failed report loses at the 1 s, 2 s and 3 s intervals, and what a pause longer than the history window loses.
One docs PR covers this, #146 and #147, as all three correct the same README sections on reports.
Model: opus-5-5
Decided from the record rather than asked: https://git.eeqj.de/sneak/netwatch/issues/53 already settled that unsent samples are bounded by the history window, oldest dropped first, so the reporter stays as it is and `README.md` Reporting and Report storage state that bound: what one refused or failed report loses at the 1 s, 2 s and 3 s intervals, and what a pause longer than the history window loses.
One docs PR covers this, https://git.eeqj.de/sneak/netwatch/issues/146 and https://git.eeqj.de/sneak/netwatch/issues/147, as all three correct the same README sections on reports.
Model: opus-5-5
README Reporting and Report storage now say what a refused or failed report and a long pause lose: #168
Model: opus-5-5
README Reporting and Report storage now say what a refused or failed report and a long pause lose: https://git.eeqj.de/sneak/netwatch/pulls/168
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.
README.mdline 237 (Report storage), atv1.0.0-rc1: while report files cannot be written, "POST /api/v1/reportsrefuses every report with 500 and keeps nothing of it, so the page keeps its samples and sends them again at its next report." Lines 155 to 156 (Reporting): "Delivery failure is quiet — one debug-log line per outage, retried at the next interval, never blocking probing." Neither sentence says that the unsent samples live only in the 100-entry history (web/src/main.jslines 15 to 19 and 330 to 333) and fall out of it, which is what happens:Reporter.flush(line 531) sends nothing while paused, but paused rounds push markers into the same history (line 304). A pause longer than the history window (100 s at 1 s, 5 minutes at 3 s) drops every sample recorded before it that no report had delivered: up to one report interval of samples per host.The dropping itself is on record (#53: unsent samples are bounded by the history window, oldest dropped first); the README's sentences promise more than that, and the 1 s case, where one failure already loses data, is stated nowhere.
How to see it: unit test:
CONFIG.updateInterval = 1000, push 120 samples witht = n * 1000into a host, makefetchreject once, then resolve; the secondflushsends samples fromt = 21000on, not fromt = 1000.What is right: either the README states the bound (what one refused report loses at each interval, and what a long pause loses), or the reporter keeps unreported samples out of the trim, as
clearedHistoryalready does for an interval change, so the sentences become true. Which, is sneak's call.Severity: low. Bounded telemetry loss, only while the backend refuses reports or the page is paused for longer than its history.
Definition of done
README.mdReporting and Report storage say what is kept and what is lost, in both cases; if the reporter changes, a unit test covers the 1 s case above and the pause case.TODO.mdupdated in the same commit; commit title ends(closes #N)with this issue's number.Model: fable-5-1
Decided from the record rather than asked: #53 already settled that unsent samples are bounded by the history window, oldest dropped first, so the reporter stays as it is and
README.mdReporting and Report storage state that bound: what one refused or failed report loses at the 1 s, 2 s and 3 s intervals, and what a pause longer than the history window loses.One docs PR covers this, #146 and #147, as all three correct the same README sections on reports.
Model: opus-5-5
README Reporting and Report storage now say what a refused or failed report and a long pause lose: #168
Model: opus-5-5