TestAVisitorThatStopsALittleShortGetsTheAppsAnswerAtOnce in internal/rproxy/limits_test.go failed the race pass of make check at a load average of about 200 on 48 cores. The branch under test, issue-311-header-limits-first, does not touch rproxy.
The failure was read the answer's body: ... i/o timeout after 10.23 s. The -v rerun in the same step passed it in 0.51 s.
The test reads the answer within the 10-second deadline of dial, so a busy host can turn next red on its own. The fix is the test's to decide, for example by not depending on that wall-clock deadline.
Model: opus-5-5
`TestAVisitorThatStopsALittleShortGetsTheAppsAnswerAtOnce` in `internal/rproxy/limits_test.go` failed the race pass of `make check` at a load average of about 200 on 48 cores. The branch under test, `issue-311-header-limits-first`, does not touch `rproxy`.
The failure was `read the answer's body: ... i/o timeout` after 10.23 s. The `-v` rerun in the same step passed it in 0.51 s.
The test reads the answer within the 10-second deadline of `dial`, so a busy host can turn `next` red on its own. The fix is the test's to decide, for example by not depending on that wall-clock deadline.
Model: opus-5-5
Plan. The failed read got the answer's status and headers, then waited past dial's 10-second deadline for a short body the app flushes with its headers, with the request time limit at 15 seconds. That looks like rproxy holding the app's body back until something else ends, not like a slow host, so the cause is found before the test is touched.
Definition of done, one PR into next:
Reproduce the failure without the race detector, uncommitted: for example run the test with -count many times beside a CPU-heavy container, or with the app's answer delayed so that it arrives after the 300 ms response time limit, or before the visitor's last bytes. Say in the PR body what ordering produces it.
If rproxy holds the answer back in that ordering, it is a defect: fix it in internal/rproxy. The PR is then two commits, first a test that reproduces it on demand and fails against current next, then the fix with no test assertion changed. SPEC.md changes only if it describes the wrong behaviour.
If only the host's load delays the answer, change the test only: it still shows the answer comes long before the request time limit, but a busy host cannot fail it, for example with the request time limit at minutes and the test's own read deadline far above any scheduling delay and far below that limit.
Either way, check the other tests in internal/rproxy/limits_test.go that read under dial's deadline while a limit counts down, and fix each that can fail the same way, or name it in the PR body with why it cannot.
No test, request or value is removed; no product limit changes.
Package: internal/rproxy, whose doc says it is the reverse proxy. Follow AGENTS.md: checks only through make targets, apart from the uncommitted reproduction runs. make fmt, then flock -w 1800 /srv/code/tmp/.gate-smallwebwaf.lock make check; a flock timeout also exits 1, so read the output. Edit by hand. Title ending (closes #318). Label the PR needs-review.
Model: opus-5-5
**Plan.** The failed read got the answer's status and headers, then waited past `dial`'s 10-second deadline for a short body the app flushes with its headers, with the request time limit at 15 seconds. That looks like `rproxy` holding the app's body back until something else ends, not like a slow host, so the cause is found before the test is touched.
**Definition of done**, one PR into `next`:
- Reproduce the failure without the race detector, uncommitted: for example run the test with `-count` many times beside a CPU-heavy container, or with the app's answer delayed so that it arrives after the 300 ms response time limit, or before the visitor's last bytes. Say in the PR body what ordering produces it.
- If `rproxy` holds the answer back in that ordering, it is a defect: fix it in `internal/rproxy`. The PR is then two commits, first a test that reproduces it on demand and fails against current `next`, then the fix with no test assertion changed. `SPEC.md` changes only if it describes the wrong behaviour.
- If only the host's load delays the answer, change the test only: it still shows the answer comes long before the request time limit, but a busy host cannot fail it, for example with the request time limit at minutes and the test's own read deadline far above any scheduling delay and far below that limit.
- Either way, check the other tests in `internal/rproxy/limits_test.go` that read under `dial`'s deadline while a limit counts down, and fix each that can fail the same way, or name it in the PR body with why it cannot.
- No test, request or value is removed; no product limit changes.
Package: `internal/rproxy`, whose doc says it is the reverse proxy. Follow `AGENTS.md`: checks only through `make` targets, apart from the uncommitted reproduction runs. `make fmt`, then `flock -w 1800 /srv/code/tmp/.gate-smallwebwaf.lock make check`; a `flock` timeout also exits 1, so read the output. Edit by hand. Title ending ` (closes #318)`. Label the PR `needs-review`.
Model: opus-5-5
clawbot
self-assigned this 2026-11-11 02:57:18 +01:00
The failure was a defect in rproxy, not only load. When more than SWRP_MAX_RESPONSE_TIME_MS passed before a short body was written, the write was cut off. Go's server then kept the connection open, reading the visitor's unfinished body until SWRP_MAX_REQUEST_TIME_MS ran out. rproxy now closes the connection at once. The two load-sensitive tests now use limits of minutes.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/smallwebwaf/pulls/322.
The failure was a defect in rproxy, not only load. When more than `SWRP_MAX_RESPONSE_TIME_MS` passed before a short body was written, the write was cut off. Go's server then kept the connection open, reading the visitor's unfinished body until `SWRP_MAX_REQUEST_TIME_MS` ran out. rproxy now closes the connection at once. The two load-sensitive tests now use limits of minutes.
Model: opus-5-5
TestAVisitorThatStopsALittleShortHasTheConnectionClosedWhenTheAnswerIsCutOff/with_the_body_in_two_parts failed once on current next (eba697a) in a full make check, and passed on the next run: limits_test.go:986: read "hello" (... i/o timeout), want the connection closed, after 10.01s. Seen while building #343, which does not touch internal/rproxy.
Model: opus-5-5
`TestAVisitorThatStopsALittleShortHasTheConnectionClosedWhenTheAnswerIsCutOff/with_the_body_in_two_parts` failed once on current `next` (`eba697a`) in a full `make check`, and passed on the next run: `limits_test.go:986: read "hello" (... i/o timeout), want the connection closed`, after 10.01s. Seen while building https://git.eeqj.de/sneak/smallwebwaf/pulls/343, which does not touch `internal/rproxy`.
Model: opus-5-5
TestAVisitorThatStopsALittleShortHasTheConnectionClosedWhenTheAnswerIsCutOff/with_the_body_in_two_parts failed again, on the first pass of two separate make test runs today: one on next at eba697a, one on #343 rebased onto it. Both times it failed at limits_test.go:986 with the same i/o timeout after 10 s, and passed on the verbose rerun. The test phase exits 1 even when the rerun passes, so make test on next fails.
Model: opus-5-5
`TestAVisitorThatStopsALittleShortHasTheConnectionClosedWhenTheAnswerIsCutOff/with_the_body_in_two_parts` failed again, on the first pass of two separate `make test` runs today: one on `next` at `eba697a`, one on https://git.eeqj.de/sneak/smallwebwaf/pulls/343 rebased onto it. Both times it failed at `limits_test.go:986` with the same i/o timeout after 10 s, and passed on the verbose rerun. The test phase exits 1 even when the rerun passes, so `make test` on `next` fails.
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.
TestAVisitorThatStopsALittleShortGetsTheAppsAnswerAtOnceininternal/rproxy/limits_test.gofailed the race pass ofmake checkat a load average of about 200 on 48 cores. The branch under test,issue-311-header-limits-first, does not touchrproxy.The failure was
read the answer's body: ... i/o timeoutafter 10.23 s. The-vrerun in the same step passed it in 0.51 s.The test reads the answer within the 10-second deadline of
dial, so a busy host can turnnextred on its own. The fix is the test's to decide, for example by not depending on that wall-clock deadline.Model: opus-5-5
Plan. The failed read got the answer's status and headers, then waited past
dial's 10-second deadline for a short body the app flushes with its headers, with the request time limit at 15 seconds. That looks likerproxyholding the app's body back until something else ends, not like a slow host, so the cause is found before the test is touched.Definition of done, one PR into
next:-countmany times beside a CPU-heavy container, or with the app's answer delayed so that it arrives after the 300 ms response time limit, or before the visitor's last bytes. Say in the PR body what ordering produces it.rproxyholds the answer back in that ordering, it is a defect: fix it ininternal/rproxy. The PR is then two commits, first a test that reproduces it on demand and fails against currentnext, then the fix with no test assertion changed.SPEC.mdchanges only if it describes the wrong behaviour.internal/rproxy/limits_test.gothat read underdial's deadline while a limit counts down, and fix each that can fail the same way, or name it in the PR body with why it cannot.Package:
internal/rproxy, whose doc says it is the reverse proxy. FollowAGENTS.md: checks only throughmaketargets, apart from the uncommitted reproduction runs.make fmt, thenflock -w 1800 /srv/code/tmp/.gate-smallwebwaf.lock make check; aflocktimeout also exits 1, so read the output. Edit by hand. Title ending(closes #318). Label the PRneeds-review.Model: opus-5-5
Built in #322.
The failure was a defect in rproxy, not only load. When more than
SWRP_MAX_RESPONSE_TIME_MSpassed before a short body was written, the write was cut off. Go's server then kept the connection open, reading the visitor's unfinished body untilSWRP_MAX_REQUEST_TIME_MSran out. rproxy now closes the connection at once. The two load-sensitive tests now use limits of minutes.Model: opus-5-5
TestAVisitorThatStopsALittleShortHasTheConnectionClosedWhenTheAnswerIsCutOff/with_the_body_in_two_partsfailed once on currentnext(eba697a) in a fullmake check, and passed on the next run:limits_test.go:986: read "hello" (... i/o timeout), want the connection closed, after 10.01s. Seen while building #343, which does not touchinternal/rproxy.Model: opus-5-5
TestAVisitorThatStopsALittleShortHasTheConnectionClosedWhenTheAnswerIsCutOff/with_the_body_in_two_partsfailed again, on the first pass of two separatemake testruns today: one onnextateba697a, one on #343 rebased onto it. Both times it failed atlimits_test.go:986with the same i/o timeout after 10 s, and passed on the verbose rerun. The test phase exits 1 even when the rerun passes, somake testonnextfails.Model: opus-5-5