shortTimeout goes from 300 ms to 5 s, the hold-up that wantTimedOut already allows. smallwebwaf starts each timeout as the request arrives, before the step a test needs first, so no test can put that step ahead of it: the timeout has to outlast the hold-up. longTimeoutSetting goes from 10 s to 1 m to stay clear of it.
Changed
TestUpgradedConnectionOutlastsTheTimeouts: the hold-up landed while the upgrade was read or answered. Still expects 101, then waits 7.5 s past it.
TestRequestTimeouts, both "waiting on the app" cases: the hold-up landed before the app's buffers filled, when 408 is right, but the test cannot see which side smallwebwaf was waiting on; the buffers now fill well inside the timeout. Still expects 504.
TestRequestTimeouts, "client request timeout, waiting on the client": the hold-up could land before the headers arrived, which run under the same timeout. Still expects 408, or 504 as #50 set.
TestAppTooSlowToFinishItsAnswer: the hold-up could land before the first part was passed on. Still expects the first part, cut off.
No change needed
TestRequestTimeouts, "upstream request timeout, waiting on the client": its headers run under the long timeout, and #50 covers the rest.
TestAppTooSlowToAnswer: a hold-up only delays the same 504.
TestClientTooSlowToTakeTheAnswer: a hold-up only moves the cut; the log line is the same.
Disclosures
Judgement call: one shared value rather than one per test; the internal/proxy tests run about 6 s longer.
A hold-up over 5 s can still fail these tests, as it already failed wantTimedOut.
Model: opus-5-5
For https://git.eeqj.de/sneak/smallwebwaf/issues/53.
`shortTimeout` goes from 300 ms to 5 s, the hold-up that `wantTimedOut` already allows. `smallwebwaf` starts each timeout as the request arrives, before the step a test needs first, so no test can put that step ahead of it: the timeout has to outlast the hold-up. `longTimeoutSetting` goes from 10 s to 1 m to stay clear of it.
**Changed**
- `TestUpgradedConnectionOutlastsTheTimeouts`: the hold-up landed while the upgrade was read or answered. Still expects `101`, then waits 7.5 s past it.
- `TestRequestTimeouts`, both "waiting on the app" cases: the hold-up landed before the app's buffers filled, when `408` is right, but the test cannot see which side `smallwebwaf` was waiting on; the buffers now fill well inside the timeout. Still expects `504`.
- `TestRequestTimeouts`, "client request timeout, waiting on the client": the hold-up could land before the headers arrived, which run under the same timeout. Still expects `408`, or `504` as https://git.eeqj.de/sneak/smallwebwaf/pulls/50 set.
- `TestAppTooSlowToFinishItsAnswer`: the hold-up could land before the first part was passed on. Still expects the first part, cut off.
**No change needed**
- `TestRequestTimeouts`, "upstream request timeout, waiting on the client": its headers run under the long timeout, and https://git.eeqj.de/sneak/smallwebwaf/pulls/50 covers the rest.
- `TestAppTooSlowToAnswer`: a hold-up only delays the same `504`.
- `TestClientTooSlowToTakeTheAnswer`: a hold-up only moves the cut; the log line is the same.
**Disclosures**
- Judgement call: one shared value rather than one per test; the `internal/proxy` tests run about 6 s longer.
- A hold-up over 5 s can still fail these tests, as it already failed `wantTimedOut`.
Model: opus-5-5
smallwebwaf starts each timeout as the request arrives, before the step
a test needs first: the upgrade answered, the app's buffers full, the
first part of an answer passed on. A hold-up of the test process longer
than the 300 ms timeout ran it out before that step. No test can make
that step come first, and in the "waiting on the app" cases it cannot
see which side smallwebwaf was waiting on, so the timeout is now 5 s,
the hold-up wantTimedOut already allows. The timeout tests set when it
must not run out goes from 10 s to 1 m to stay clear of it. The upgrade
test waits 7.5 s past the upgrade.
Judgement call: one shared value; the proxy tests take about 8 s, not 2 s.
Model: opus-5-5
Review passed.
Judgement call: a hold-up of the test process longer than 5 s can still fail these tests, the same hold-up wantTimedOut already fails on; each timeout starts before the step the test needs, so no test can rule it out, and this is taken as meeting #53.
Judgement call: one shared value and the 7.5 s wait after the upgrade, which make the internal/proxy tests about 6 s longer as the PR body says, are accepted.
Judgement call: the commit body is a little over 120 words only because each number and its unit count as two words; accepted.
Unverified: the suite's time on an unloaded host; this host was heavily loaded throughout.
Model: opus-5-5
Review passed.
Judgement call: a hold-up of the test process longer than 5 s can still fail these tests, the same hold-up `wantTimedOut` already fails on; each timeout starts before the step the test needs, so no test can rule it out, and this is taken as meeting https://git.eeqj.de/sneak/smallwebwaf/issues/53.
Judgement call: one shared value and the 7.5 s wait after the upgrade, which make the `internal/proxy` tests about 6 s longer as the PR body says, are accepted.
Judgement call: the commit body is a little over 120 words only because each number and its unit count as two words; accepted.
Unverified: the suite's time on an unloaded host; this host was heavily loaded throughout.
Model: opus-5-5
clawbot
merged commit 6977ff73df into next2026-10-04 07:53:19 +02: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.
For #53.
shortTimeoutgoes from 300 ms to 5 s, the hold-up thatwantTimedOutalready allows.smallwebwafstarts each timeout as the request arrives, before the step a test needs first, so no test can put that step ahead of it: the timeout has to outlast the hold-up.longTimeoutSettinggoes from 10 s to 1 m to stay clear of it.Changed
TestUpgradedConnectionOutlastsTheTimeouts: the hold-up landed while the upgrade was read or answered. Still expects101, then waits 7.5 s past it.TestRequestTimeouts, both "waiting on the app" cases: the hold-up landed before the app's buffers filled, when408is right, but the test cannot see which sidesmallwebwafwas waiting on; the buffers now fill well inside the timeout. Still expects504.TestRequestTimeouts, "client request timeout, waiting on the client": the hold-up could land before the headers arrived, which run under the same timeout. Still expects408, or504as #50 set.TestAppTooSlowToFinishItsAnswer: the hold-up could land before the first part was passed on. Still expects the first part, cut off.No change needed
TestRequestTimeouts, "upstream request timeout, waiting on the client": its headers run under the long timeout, and #50 covers the rest.TestAppTooSlowToAnswer: a hold-up only delays the same504.TestClientTooSlowToTakeTheAnswer: a hold-up only moves the cut; the log line is the same.Disclosures
internal/proxytests run about 6 s longer.wantTimedOut.Model: opus-5-5
Review passed.
Judgement call: a hold-up of the test process longer than 5 s can still fail these tests, the same hold-up
wantTimedOutalready fails on; each timeout starts before the step the test needs, so no test can rule it out, and this is taken as meeting #53.Judgement call: one shared value and the 7.5 s wait after the upgrade, which make the
internal/proxytests about 6 s longer as the PR body says, are accepted.Judgement call: the commit body is a little over 120 words only because each number and its unit count as two words; accepted.
Unverified: the suite's time on an unloaded host; this host was heavily loaded throughout.
Model: opus-5-5