TestAnAppTooSlowToFinishItsAnswerIsCutOff (internal/rproxy/limits_test.go, line 602) failed on next at 344ce13, in the image build's test stage during make example-app; make check on the same commit passed.
limits_test.go:626: read: read tcp 127.0.0.1:51634->127.0.0.1:35111: i/o timeout, want the connection closed
limits_test.go:630: report {... Status:504 RequestBytes:0 ResponseBytes:16 DurationTotal:589.431 DurationUpstreamTotal:510.15}, want the status the visitor got
The test means to check an answer cut off after it has started: the app flushes "the start" and then hangs, and SWRP_MAX_RESPONSE_TIME_MS is 300. On a loaded host the 300 ms ran out before rproxy had passed on the first byte, so rproxy answered 504 itself, as it should for an answer that has not started, and kept the connection open, so the test's read waited out its deadline. The test depends on timing.
Definition of done
The test checks what its name says, an answer cut off after its start has reached the visitor, without depending on how fast the host is: for instance, it reads the start before the time limit can matter, with a limit long enough for that on a loaded host.
If the test shows rproxy doing something other than SPEC.md says, that is fixed in internal/rproxy and named in the PR; otherwise only the test changes.
Any other test in internal/rproxy that depends on the host's speed in the same way is fixed the same way, each named in the PR.
Model: opus-5-5
`TestAnAppTooSlowToFinishItsAnswerIsCutOff` (`internal/rproxy/limits_test.go`, line 602) failed on `next` at `344ce13`, in the image build's test stage during `make example-app`; `make check` on the same commit passed.
```
limits_test.go:626: read: read tcp 127.0.0.1:51634->127.0.0.1:35111: i/o timeout, want the connection closed
limits_test.go:630: report {... Status:504 RequestBytes:0 ResponseBytes:16 DurationTotal:589.431 DurationUpstreamTotal:510.15}, want the status the visitor got
```
The test means to check an answer cut off after it has started: the app flushes "the start" and then hangs, and `SWRP_MAX_RESPONSE_TIME_MS` is 300. On a loaded host the 300 ms ran out before rproxy had passed on the first byte, so rproxy answered `504` itself, as it should for an answer that has not started, and kept the connection open, so the test's read waited out its deadline. The test depends on timing.
## Definition of done
- The test checks what its name says, an answer cut off after its start has reached the visitor, without depending on how fast the host is: for instance, it reads the start before the time limit can matter, with a limit long enough for that on a loaded host.
- If the test shows rproxy doing something other than `SPEC.md` says, that is fixed in `internal/rproxy` and named in the PR; otherwise only the test changes.
- Any other test in `internal/rproxy` that depends on the host's speed in the same way is fixed the same way, each named in the PR.
Model: opus-5-5
clawbot
self-assigned this 2026-11-05 13:18:52 +01:00
#186 gives four rproxy tests a 3-second limit in place of one of a second or less, this test among them. rproxy did what SPEC.md says, so only the tests change.
Judgement call: tests whose limits already give 2 seconds or more are left as they are.
Model: opus-5-5
https://git.eeqj.de/sneak/smallwebwaf/pulls/186 gives four rproxy tests a 3-second limit in place of one of a second or less, this test among them. rproxy did what `SPEC.md` says, so only the tests change.
Judgement call: tests whose limits already give 2 seconds or more are left as they are.
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.
TestAnAppTooSlowToFinishItsAnswerIsCutOff(internal/rproxy/limits_test.go, line 602) failed onnextat344ce13, in the image build's test stage duringmake example-app;make checkon the same commit passed.The test means to check an answer cut off after it has started: the app flushes "the start" and then hangs, and
SWRP_MAX_RESPONSE_TIME_MSis 300. On a loaded host the 300 ms ran out before rproxy had passed on the first byte, so rproxy answered504itself, as it should for an answer that has not started, and kept the connection open, so the test's read waited out its deadline. The test depends on timing.Definition of done
SPEC.mdsays, that is fixed ininternal/rproxyand named in the PR; otherwise only the test changes.internal/rproxythat depends on the host's speed in the same way is fixed the same way, each named in the PR.Model: opus-5-5
#186 gives four rproxy tests a 3-second limit in place of one of a second or less, this test among them. rproxy did what
SPEC.mdsays, so only the tests change.Judgement call: tests whose limits already give 2 seconds or more are left as they are.
Model: opus-5-5