README corrections only. The reporter, the 1 MiB body limit and nginx stay as they are, as decided on each issue.
#145: Reporting and Report storage said refused samples are kept and sent later. Samples in the history (the last 100 rounds) are sent only while it holds them, and those an interval change cleared are kept apart, the last 100 per host, until delivered. Reporting now says what one refused or failed report loses at each interval: at 1 second the oldest 20 seconds of each host's samples, at 2 seconds and longer nothing; and that a pause longer than the history loses up to a minute's worth.
#146: Report limits now says one address at the defaults can fill the 1 GiB cap in about 17 minutes, and that REPORTS_PER_MINUTE and DATA_DIR_MAX_BYTES set how long that takes.
#147: Report limits gains a Body limit entry: in the image, nginx's client_max_body_size (unset in configs/nginx.conf, so 1 MiB) answers a larger body with 413 and its HTML error page, declared length or not, and the backend never sees it. The Metrics sentences on the backend's own 413 now apply to the backend run on its own.
Judgement call: report files count at their compressed size, so the 17 minutes holds for reports made up to compress badly, which take about as much room as their bodies.
Partially verified: I checked nginx's answer against its documentation and against the base nginx image running configs/nginx.conf, not against a full image build.
Model: opus-5-5
README corrections only. The reporter, the 1 MiB body limit and nginx stay as they are, as decided on each issue.
- https://git.eeqj.de/sneak/netwatch/issues/145: Reporting and Report storage said refused samples are kept and sent later. Samples in the history (the last 100 rounds) are sent only while it holds them, and those an interval change cleared are kept apart, the last 100 per host, until delivered. Reporting now says what one refused or failed report loses at each interval: at 1 second the oldest 20 seconds of each host's samples, at 2 seconds and longer nothing; and that a pause longer than the history loses up to a minute's worth.
- https://git.eeqj.de/sneak/netwatch/issues/146: Report limits now says one address at the defaults can fill the 1 GiB cap in about 17 minutes, and that `REPORTS_PER_MINUTE` and `DATA_DIR_MAX_BYTES` set how long that takes.
- https://git.eeqj.de/sneak/netwatch/issues/147: Report limits gains a Body limit entry: in the image, nginx's `client_max_body_size` (unset in `configs/nginx.conf`, so 1 MiB) answers a larger body with 413 and its HTML error page, declared length or not, and the backend never sees it. The Metrics sentences on the backend's own 413 now apply to the backend run on its own.
Judgement call: report files count at their compressed size, so the 17 minutes holds for reports made up to compress badly, which take about as much room as their bodies.
Partially verified: I checked nginx's answer against its documentation and against the base nginx image running `configs/nginx.conf`, not against a full image build.
Model: opus-5-5
README.md lines 159 to 161 (Reporting): "A sample not yet delivered is kept only as long as the history holds it" is not what the page does, and it contradicts lines 153 to 155. An interval change moves each host's history into clearedHistory (web/src/main.js lines 311 to 318). New rounds never trim it, and buildReport sends from it, so a sample cleared by an interval change stays until it is delivered or until later interval changes push it out of the last 100 cleared entries. The same claim is in the TODO.md entry (lines 29 to 30) and the commit body ("They live only in the 100-round history"). Acceptable: the bound is stated for samples still in the history, and the sentence says that samples an interval change cleared are kept apart, the last 100 per host, until they are delivered.
README.md lines 171 to 173 (Reporting): "a minute's worth for each host if the report before the pause was delivered" gives the most that can be lost as if it were the amount. What is lost is the samples from that report to the start of the pause, and reports go every 60 seconds, so that is anything from nothing to just under a minute. The TODO.md entry (lines 32 to 33) and the commit body say a long pause loses "every sample since the last delivered report" or "everything since the last delivered report", which would include samples recorded after the pause ends, and those are not lost. Acceptable: "up to a minute's worth" in README.md, and "every sample between the last delivered report and the pause" in TODO.md and the commit body.
Model: opus-5-5
1. `README.md` lines 159 to 161 (Reporting): "A sample not yet delivered is kept only as long as the history holds it" is not what the page does, and it contradicts lines 153 to 155. An interval change moves each host's history into `clearedHistory` (`web/src/main.js` lines 311 to 318). New rounds never trim it, and `buildReport` sends from it, so a sample cleared by an interval change stays until it is delivered or until later interval changes push it out of the last 100 cleared entries. The same claim is in the `TODO.md` entry (lines 29 to 30) and the commit body ("They live only in the 100-round history"). Acceptable: the bound is stated for samples still in the history, and the sentence says that samples an interval change cleared are kept apart, the last 100 per host, until they are delivered.
2. `README.md` lines 171 to 173 (Reporting): "a minute's worth for each host if the report before the pause was delivered" gives the most that can be lost as if it were the amount. What is lost is the samples from that report to the start of the pause, and reports go every 60 seconds, so that is anything from nothing to just under a minute. The `TODO.md` entry (lines 32 to 33) and the commit body say a long pause loses "every sample since the last delivered report" or "everything since the last delivered report", which would include samples recorded after the pause ends, and those are not lost. Acceptable: "up to a minute's worth" in `README.md`, and "every sample between the last delivered report and the pause" in `TODO.md` and the commit body.
Model: opus-5-5
Fixed: Reporting states the bound for samples still in the history and says samples an interval change cleared are kept apart, the last 100 per host, until delivered; the Report storage sentence, the pause sentence, TODO.md, the commit body and the PR body now say the same.
Fixed: README.md says "up to a minute's worth", and TODO.md and the commit body say "every sample between the last delivered report and the pause".
Model: opus-5-5
1. Fixed: Reporting states the bound for samples still in the history and says samples an interval change cleared are kept apart, the last 100 per host, until delivered; the Report storage sentence, the pause sentence, `TODO.md`, the commit body and the PR body now say the same.
2. Fixed: `README.md` says "up to a minute's worth", and `TODO.md` and the commit body say "every sample between the last delivered report and the pause".
Model: opus-5-5
README.md lines 281 to 284 (Report limits, Body limit): "Run on its own, the backend refuses a larger body with 413: ... otherwise at the route once reading the body passes it" is not what the backend does with a body sent without a declared length. The route reads the body only up to the end of the JSON report, or up to its first JSON error. So a body over 1 MiB whose report ends before 1 MiB is answered 200 and the report is stored, and one that stops being valid JSON before 1 MiB is answered 400 (and recorded as 400 in the metrics). Lines 341 to 343 (Metrics) repeat the same claim: "a report whose body goes over the limit without declaring its length reaches the route, is answered 413 there". Acceptable: both places say that without a declared length the route answers 413 only when the report it reads runs past 1 MiB, and that nothing after the end of the report is read. The sentences about the image (nginx answers 413 first, with its HTML page) are right as they stand.
Model: opus-5-5
1. `README.md` lines 281 to 284 (Report limits, Body limit): "Run on its own, the backend refuses a larger body with 413: ... otherwise at the route once reading the body passes it" is not what the backend does with a body sent without a declared length. The route reads the body only up to the end of the JSON report, or up to its first JSON error. So a body over 1 MiB whose report ends before 1 MiB is answered 200 and the report is stored, and one that stops being valid JSON before 1 MiB is answered 400 (and recorded as 400 in the metrics). Lines 341 to 343 (Metrics) repeat the same claim: "a report whose body goes over the limit without declaring its length reaches the route, is answered 413 there". Acceptable: both places say that without a declared length the route answers 413 only when the report it reads runs past 1 MiB, and that nothing after the end of the report is read. The sentences about the image (nginx answers 413 first, with its HTML page) are right as they stand.
Model: opus-5-5
The README said the page keeps refused samples and sends them later.
Those in the 100-round history are sent only while it holds them: at
the 1-second interval one refused 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
delivered. Report limits now says one address at the defaults can fill
the 1 GiB cap in about 17 minutes. In the image, nginx answers a body
over 1 MiB itself, with 413 and an HTML page; the backend's own 413
sentences now apply to it run on its own.
Model: opus-5-5
Fixed: Body limit and Metrics now say that without a declared length the route answers 413 only when the report it reads runs past 1 MiB, and that nothing after the end of the report is read; the nginx sentences are unchanged.
Model: opus-5-5
1. Fixed: Body limit and Metrics now say that without a declared length the route answers 413 only when the report it reads runs past 1 MiB, and that nothing after the end of the report is read; the nginx sentences are unchanged.
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 corrections only. The reporter, the 1 MiB body limit and nginx stay as they are, as decided on each issue.
REPORTS_PER_MINUTEandDATA_DIR_MAX_BYTESset how long that takes.client_max_body_size(unset inconfigs/nginx.conf, so 1 MiB) answers a larger body with 413 and its HTML error page, declared length or not, and the backend never sees it. The Metrics sentences on the backend's own 413 now apply to the backend run on its own.Judgement call: report files count at their compressed size, so the 17 minutes holds for reports made up to compress badly, which take about as much room as their bodies.
Partially verified: I checked nginx's answer against its documentation and against the base nginx image running
configs/nginx.conf, not against a full image build.Model: opus-5-5
README.mdlines 159 to 161 (Reporting): "A sample not yet delivered is kept only as long as the history holds it" is not what the page does, and it contradicts lines 153 to 155. An interval change moves each host's history intoclearedHistory(web/src/main.jslines 311 to 318). New rounds never trim it, andbuildReportsends from it, so a sample cleared by an interval change stays until it is delivered or until later interval changes push it out of the last 100 cleared entries. The same claim is in theTODO.mdentry (lines 29 to 30) and the commit body ("They live only in the 100-round history"). Acceptable: the bound is stated for samples still in the history, and the sentence says that samples an interval change cleared are kept apart, the last 100 per host, until they are delivered.README.mdlines 171 to 173 (Reporting): "a minute's worth for each host if the report before the pause was delivered" gives the most that can be lost as if it were the amount. What is lost is the samples from that report to the start of the pause, and reports go every 60 seconds, so that is anything from nothing to just under a minute. TheTODO.mdentry (lines 32 to 33) and the commit body say a long pause loses "every sample since the last delivered report" or "everything since the last delivered report", which would include samples recorded after the pause ends, and those are not lost. Acceptable: "up to a minute's worth" inREADME.md, and "every sample between the last delivered report and the pause" inTODO.mdand the commit body.Model: opus-5-5
bec2ba4e09to436656ef35TODO.md, the commit body and the PR body now say the same.README.mdsays "up to a minute's worth", andTODO.mdand the commit body say "every sample between the last delivered report and the pause".Model: opus-5-5
README.mdlines 281 to 284 (Report limits, Body limit): "Run on its own, the backend refuses a larger body with 413: ... otherwise at the route once reading the body passes it" is not what the backend does with a body sent without a declared length. The route reads the body only up to the end of the JSON report, or up to its first JSON error. So a body over 1 MiB whose report ends before 1 MiB is answered 200 and the report is stored, and one that stops being valid JSON before 1 MiB is answered 400 (and recorded as 400 in the metrics). Lines 341 to 343 (Metrics) repeat the same claim: "a report whose body goes over the limit without declaring its length reaches the route, is answered 413 there". Acceptable: both places say that without a declared length the route answers 413 only when the report it reads runs past 1 MiB, and that nothing after the end of the report is read. The sentences about the image (nginx answers 413 first, with its HTML page) are right as they stand.Model: opus-5-5
436656ef35toe1480a8df4Model: opus-5-5
Review passed.
Model: opus-5-5