Not blocking: a fault in a test, which need not be fixed before real traffic. Found while building next at f7e3190 for the end-to-end check of sww rproxy (#321).
Where
internal/rproxy/rproxy_test.go, TestAnAnswerThatCannotBePassedOnIsAnswered502: the three cases whose waf answers with a body over 1 MiB (overOneMiB).
What is wrong
The cases leave SWRP_TIMEOUT_MS at its default of 2 s. On a busy host rproxy had not read the whole answer of 1 MiB and one byte when that time ran out, so it applied SWRP_DEFAULT_DISPOSITION, as it should. The test wants 502 and fails. rproxy did nothing wrong.
Seen in the first make docker; the second passed:
Cases: "an allow over 1 MiB with the default deny", "a deny over 1 MiB with the default allow", "no header over 1 MiB with the default deny".
rproxy_test.go:1124: answered 503 with the default deny and 200 with the default allow (rproxy_test.go:1117: the app was asked), want 502.
rproxy_test.go:1130: the log line had default_disposition:true and a duration_request_ms of about 3000.
rproxy_test.go:1133: rproxy did not write "waf's answer is dropped".
Why it matters
make docker and make check fail at random on a loaded host, and a failed check holds up a PR that changed nothing here. It is the same kind of fault as #318 (the visitor that stops a little short) and #316 (the answer-time check), in a different test.
Acceptable
The three cases pass however slow the host is. Other tests in the file set SWRP_TIMEOUT_MS to 60000 where the time limit is not what they test; these cases can do the same.
Definition of done
One PR to next that changes the test only.
make check passes.
Model: fable-5-2
Not blocking: a fault in a test, which need not be fixed before real traffic. Found while building `next` at `f7e3190` for the end-to-end check of `sww rproxy` (https://git.eeqj.de/sneak/smallwebwaf/issues/321).
## Where
`internal/rproxy/rproxy_test.go`, `TestAnAnswerThatCannotBePassedOnIsAnswered502`: the three cases whose `waf` answers with a body over 1 MiB (`overOneMiB`).
## What is wrong
The cases leave `SWRP_TIMEOUT_MS` at its default of 2 s. On a busy host `rproxy` had not read the whole answer of 1 MiB and one byte when that time ran out, so it applied `SWRP_DEFAULT_DISPOSITION`, as it should. The test wants `502` and fails. `rproxy` did nothing wrong.
Seen in the first `make docker`; the second passed:
- Cases: "an allow over 1 MiB with the default deny", "a deny over 1 MiB with the default allow", "no header over 1 MiB with the default deny".
- `rproxy_test.go:1124`: answered `503` with the default `deny` and `200` with the default `allow` (`rproxy_test.go:1117: the app was asked`), want `502`.
- `rproxy_test.go:1130`: the log line had `default_disposition:true` and a `duration_request_ms` of about 3000.
- `rproxy_test.go:1133`: `rproxy did not write "waf's answer is dropped"`.
## Why it matters
`make docker` and `make check` fail at random on a loaded host, and a failed check holds up a PR that changed nothing here. It is the same kind of fault as https://git.eeqj.de/sneak/smallwebwaf/issues/318 (the visitor that stops a little short) and https://git.eeqj.de/sneak/smallwebwaf/issues/316 (the answer-time check), in a different test.
## Acceptable
The three cases pass however slow the host is. Other tests in the file set `SWRP_TIMEOUT_MS` to `60000` where the time limit is not what they test; these cases can do the same.
## Definition of done
- One PR to `next` that changes the test only.
- `make check` passes.
Model: fable-5-2
Plan. Test only, in internal/rproxy/rproxy_test.go: the three cases of TestAnAnswerThatCannotBePassedOnIsAnswered502 with a body over 1 MiB set SWRP_TIMEOUT_MS to 60000, as the file's other tests do where that limit is not what they test. No test, request or value is removed; no product limit changes. If #322 has landed, start from it.
Follow AGENTS.md: checks only through make targets. 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 #323). Label the PR needs-review.
Model: opus-5-5
**Plan.** Test only, in `internal/rproxy/rproxy_test.go`: the three cases of `TestAnAnswerThatCannotBePassedOnIsAnswered502` with a body over 1 MiB set `SWRP_TIMEOUT_MS` to `60000`, as the file's other tests do where that limit is not what they test. No test, request or value is removed; no product limit changes. If https://git.eeqj.de/sneak/smallwebwaf/pulls/322 has landed, start from it.
Follow `AGENTS.md`: checks only through `make` targets. `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 #323)`. Label the PR `needs-review`.
Model: opus-5-5
clawbot
self-assigned this 2026-11-11 04:11:39 +01:00
Built in #328: both tests that send an over-1 MiB answer now set SWRP_TIMEOUT_MS to 60000. That covers the three cases named here and also TestAnAnswerThatCannotBePassedOnGetsNoReport, which had the same fault.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/smallwebwaf/pulls/328: both tests that send an over-1 MiB answer now set `SWRP_TIMEOUT_MS` to `60000`. That covers the three cases named here and also `TestAnAnswerThatCannotBePassedOnGetsNoReport`, which had the same fault.
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.
Not blocking: a fault in a test, which need not be fixed before real traffic. Found while building
nextatf7e3190for the end-to-end check ofsww rproxy(#321).Where
internal/rproxy/rproxy_test.go,TestAnAnswerThatCannotBePassedOnIsAnswered502: the three cases whosewafanswers with a body over 1 MiB (overOneMiB).What is wrong
The cases leave
SWRP_TIMEOUT_MSat its default of 2 s. On a busy hostrproxyhad not read the whole answer of 1 MiB and one byte when that time ran out, so it appliedSWRP_DEFAULT_DISPOSITION, as it should. The test wants502and fails.rproxydid nothing wrong.Seen in the first
make docker; the second passed:rproxy_test.go:1124: answered503with the defaultdenyand200with the defaultallow(rproxy_test.go:1117: the app was asked), want502.rproxy_test.go:1130: the log line haddefault_disposition:trueand aduration_request_msof about 3000.rproxy_test.go:1133:rproxy did not write "waf's answer is dropped".Why it matters
make dockerandmake checkfail at random on a loaded host, and a failed check holds up a PR that changed nothing here. It is the same kind of fault as #318 (the visitor that stops a little short) and #316 (the answer-time check), in a different test.Acceptable
The three cases pass however slow the host is. Other tests in the file set
SWRP_TIMEOUT_MSto60000where the time limit is not what they test; these cases can do the same.Definition of done
nextthat changes the test only.make checkpasses.Model: fable-5-2
Plan. Test only, in
internal/rproxy/rproxy_test.go: the three cases ofTestAnAnswerThatCannotBePassedOnIsAnswered502with a body over 1 MiB setSWRP_TIMEOUT_MSto60000, as the file's other tests do where that limit is not what they test. No test, request or value is removed; no product limit changes. If #322 has landed, start from it.Follow
AGENTS.md: checks only throughmaketargets.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 #323). Label the PRneeds-review.Model: opus-5-5
Built in #328: both tests that send an over-1 MiB answer now set
SWRP_TIMEOUT_MSto60000. That covers the three cases named here and alsoTestAnAnswerThatCannotBePassedOnGetsNoReport, which had the same fault.Model: opus-5-5