Four tests in internal/rproxy set a time limit of a second or less, and each needs one step done before that limit runs out. On a loaded host the limit ran out first. rproxy then answered as SPEC.md says it should, and the test failed, as #185 reports. Only the tests change. Each limit is now 3 seconds:
TestAnAppTooSlowToFinishItsAnswerIsCutOff (was 300 ms): the start of the answer must reach the visitor first. The test now also checks that the visitor got the app's 200 and the start, and that the connection then closed in the middle of the answer.
TestAVisitorTooSlowToTakeTheAnswerIsCutOff (was 500 ms): the answer must start first.
TestAVisitorThatStopsSendingGetsAnAnswerRProxyGivesByTheDeadline (was 500 ms): rproxy must read the first part of the body first.
TestAReportServeWAFLeavesUnansweredIsDroppedAtTheTimeLimit (was 1 second): servewaf must answer the question first.
Each of these tests waits out its limit, so each now takes about 3 seconds. They run in parallel with the rest of the package.
How I checked it: in a scratch copy I delayed the step each test needs by 1 second, under the old limits and under the new ones; I also ran the changed tests many times beside the whole package, pinned to two CPUs, with the processes paused at intervals.
Judgement call: tests whose limits give 2 seconds or more are left as they are. Every test that asks servewaf already needs its answer within 2 seconds, the default of SWRP_TIMEOUT_MS.
Model: opus-5-5
Four tests in `internal/rproxy` set a time limit of a second or less, and each needs one step done before that limit runs out. On a loaded host the limit ran out first. rproxy then answered as `SPEC.md` says it should, and the test failed, as https://git.eeqj.de/sneak/smallwebwaf/issues/185 reports. Only the tests change. Each limit is now 3 seconds:
- `TestAnAppTooSlowToFinishItsAnswerIsCutOff` (was 300 ms): the start of the answer must reach the visitor first. The test now also checks that the visitor got the app's `200` and the start, and that the connection then closed in the middle of the answer.
- `TestAVisitorTooSlowToTakeTheAnswerIsCutOff` (was 500 ms): the answer must start first.
- `TestAVisitorThatStopsSendingGetsAnAnswerRProxyGivesByTheDeadline` (was 500 ms): rproxy must read the first part of the body first.
- `TestAReportServeWAFLeavesUnansweredIsDroppedAtTheTimeLimit` (was 1 second): servewaf must answer the question first.
Each of these tests waits out its limit, so each now takes about 3 seconds. They run in parallel with the rest of the package.
How I checked it: in a scratch copy I delayed the step each test needs by 1 second, under the old limits and under the new ones; I also ran the changed tests many times beside the whole package, pinned to two CPUs, with the processes paused at intervals.
Judgement call: tests whose limits give 2 seconds or more are left as they are. Every test that asks servewaf already needs its answer within 2 seconds, the default of `SWRP_TIMEOUT_MS`.
Model: opus-5-5
Four rproxy tests set a time limit of a second or less, and each needed a
step done before that limit ran out. On a loaded host the limit ran out
first, rproxy answered as SPEC.md says it should, and the test failed. Each
of these limits is now 3 seconds:
- TestAnAppTooSlowToFinishItsAnswerIsCutOff, which now also checks that the
visitor got the app's 200 and the start of its answer;
- TestAVisitorTooSlowToTakeTheAnswerIsCutOff;
- TestAVisitorThatStopsSendingGetsAnAnswerRProxyGivesByTheDeadline;
- TestAReportServeWAFLeavesUnansweredIsDroppedAtTheTimeLimit.
Judgement call: tests whose limits already give 2 seconds or more are left as
they are.
Model: opus-5-5
PASS: the four rproxy tests now give a loaded host time to finish each step before their limits run out, and they still check what their names say.
Model: opus-5-5
PASS: the four rproxy tests now give a loaded host time to finish each step before their limits run out, and they still check what their names say.
Model: opus-5-5
clawbot
merged commit 8632da556a into next2026-11-05 23:17:17 +01:00
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.
Four tests in
internal/rproxyset a time limit of a second or less, and each needs one step done before that limit runs out. On a loaded host the limit ran out first. rproxy then answered asSPEC.mdsays it should, and the test failed, as #185 reports. Only the tests change. Each limit is now 3 seconds:TestAnAppTooSlowToFinishItsAnswerIsCutOff(was 300 ms): the start of the answer must reach the visitor first. The test now also checks that the visitor got the app's200and the start, and that the connection then closed in the middle of the answer.TestAVisitorTooSlowToTakeTheAnswerIsCutOff(was 500 ms): the answer must start first.TestAVisitorThatStopsSendingGetsAnAnswerRProxyGivesByTheDeadline(was 500 ms): rproxy must read the first part of the body first.TestAReportServeWAFLeavesUnansweredIsDroppedAtTheTimeLimit(was 1 second): servewaf must answer the question first.Each of these tests waits out its limit, so each now takes about 3 seconds. They run in parallel with the rest of the package.
How I checked it: in a scratch copy I delayed the step each test needs by 1 second, under the old limits and under the new ones; I also ran the changed tests many times beside the whole package, pinned to two CPUs, with the processes paused at intervals.
Judgement call: tests whose limits give 2 seconds or more are left as they are. Every test that asks servewaf already needs its answer within 2 seconds, the default of
SWRP_TIMEOUT_MS.Model: opus-5-5
PASS: the four rproxy tests now give a loaded host time to finish each step before their limits run out, and they still check what their names say.
Model: opus-5-5