1 Commits
Author SHA1 Message Date
sneak bec2ba4e09 README states what refused reports, one sender and nginx's 413 do (closes #145, closes #146, closes #147)
check / check (push) Canceled after 0s
The README said the page keeps refused samples and sends them later.
They live only in the 100-round history, so at the 1-second interval
one refused or failed report loses the oldest 20 seconds of each host's
samples, and a pause longer than the history loses everything since the
last delivered report. Report limits now says one address at the
defaults can fill the 1 GiB cap in about 17 minutes with reports made to
compress badly, and which settings bound it. In the image, nginx's
default client_max_body_size of 1 MiB answers an over-limit body with
413 and an HTML page before the backend sees it; the backend's own 413
sentences now say they apply to it run on its own.

Model: opus-5-5
2026-10-18 23:40:10 +00:00
2 changed files with 23 additions and 27 deletions
+17 -19
View File
@@ -156,23 +156,21 @@ the next report. Delivery failure is quiet — one debug-log line per outage,
never blocking probing. The report-building step is a pure function of host
state.
A sample in the history that no report has delivered is sent only as long as the
history holds it, so after a refused or failed report the next report carries
the samples the history still has. Samples an interval change cleared from the
history are kept apart, the last 100 per host, until they are delivered. The
history keeps each host's last 100 rounds: 100 seconds at the 1-second interval,
200 seconds at 2 seconds, 5 minutes at the default of 3 seconds and 100 minutes
at 60 seconds. At 1 second, one refused or failed report loses the oldest 20
seconds of each host's samples, as the next delivered report comes 2 minutes
after the last. At 2 seconds and longer one loses nothing; samples are lost from
the third refused report in a row at 2 seconds, from the fifth at 3 seconds, and
later still at the longer intervals.
A sample not yet delivered is kept only as long as the history holds it, so
after a refused or failed report the next report carries the samples the history
still has. The history keeps each host's last 100 rounds: 100 seconds at the
1-second interval, 200 seconds at 2 seconds, 5 minutes at the default of 3
seconds and 100 minutes at 60 seconds. At 1 second, one refused or failed report
loses the oldest 20 seconds of each host's samples, as the next delivered report
comes 2 minutes after the last. At 2 seconds and longer one loses nothing;
samples are lost from the third refused report in a row at 2 seconds, from the
fifth at 3 seconds, and later still at the longer intervals.
No report is sent while the page is paused, but each paused round still adds an
entry to the history, so each report due during a pause counts as a refused one.
A pause longer than the history spans loses the samples in the history recorded
between the last delivered report and the pause: up to a minute's worth for each
host if the report before the pause was delivered.
A pause longer than the history spans loses every sample recorded between the
last delivered report and the pause: a minute's worth for each host if the
report before the pause was delivered.
### Backend
@@ -259,11 +257,11 @@ Files are created with `O_EXCL` to prevent overwrites.
The reports of a failed write stay in memory, and the next flush, within a
minute, tries again to write them. From the failed write until a write succeeds,
`POST /api/v1/reports` refuses every report with 500 and keeps nothing of it.
The page sends the refused samples again in its next report, as long as it still
holds them: at the 1-second interval one refused report already loses some of
those in the history (see [Reporting](#reporting)). Reports already answered 200
are lost only if the server stops before a write succeeds; the final flush at
stop tries them too, and if it fails, the process exits non-zero.
The page sends the refused samples again in its next report, as long as its
history still holds them: at the 1-second interval one refused report already
loses some (see [Reporting](#reporting)). Reports already answered 200 are lost
only if the server stops before a write succeeds; the final flush at stop tries
them too, and if it fails, the process exits non-zero.
#### Report limits
+6 -8
View File
@@ -26,14 +26,12 @@ Run `make frontend-viewport-test` in CI as its own step; it is not part of
how fast one address can replace the stored reports
([#146](https://git.eeqj.de/sneak/netwatch/issues/146)), and that in the image
nginx answers a body over 1 MiB itself
([#147](https://git.eeqj.de/sneak/netwatch/issues/147)). A sample in the
history that no report has delivered is sent only as long as the history holds
it: at the 1-second interval one refused or failed report loses the oldest 20
seconds of each host's samples, and a pause longer than the history loses
every sample between the last delivered report and the pause. Samples an
interval change cleared are kept apart, the last 100 per host, until they are
delivered. At the defaults, one address sending 1 MiB reports made up to
compress badly can fill the 1 GiB cap in about 17 minutes. nginx's
([#147](https://git.eeqj.de/sneak/netwatch/issues/147)). A sample not yet
delivered is kept only as long as the history holds it: at the 1-second
interval one refused or failed report loses the oldest 20 seconds of each
host's samples, and a pause longer than the history loses every sample since
the last delivered report. At the defaults, one address sending 1 MiB reports
made up to compress badly can fill the 1 GiB cap in about 17 minutes. nginx's
`client_max_body_size` is also 1 MiB by default, so in the image it answers a
larger body with 413 and its own HTML page, and the backend never sees or
records it; the backend's own 413 sentences now say they apply to it run on