Cause. In the two cases where the app reads and the client stops sending halfway, smallwebwaf waits on the client only once it has passed the first bytes of the body to the app; until then it is waiting on the app, and SPEC.md asks for 504. A test process held up for the whole 300 ms timeout before that point therefore rightly gets 504, and the test was wrong to expect 408 every time.
Change. The app in those cases records whether it received any of the body. Once the app has finished with the request, the case expects 408 and its log line if it did, and 504 and its log line if not. No change to smallwebwaf itself.
Not in the diff.app.Close() is what keeps the test from reading the app's record too early: it returns only once the app's connection has closed. The cleanup that startApp registers calls it again, which does nothing.
Disclosures
Unverified: a hold-up that ends in the few microseconds between smallwebwaf passing the first bytes to the app and asking the client for more, or one that stalls only the app's reading of a request it was already sent, can still make the case fail.
Model: opus-5-5
For https://git.eeqj.de/sneak/smallwebwaf/issues/49.
**Cause.** In the two cases where the app reads and the client stops sending halfway, smallwebwaf waits on the client only once it has passed the first bytes of the body to the app; until then it is waiting on the app, and `SPEC.md` asks for `504`. A test process held up for the whole 300 ms timeout before that point therefore rightly gets `504`, and the test was wrong to expect `408` every time.
**Change.** The app in those cases records whether it received any of the body. Once the app has finished with the request, the case expects `408` and its log line if it did, and `504` and its log line if not. No change to smallwebwaf itself.
**Not in the diff.** `app.Close()` is what keeps the test from reading the app's record too early: it returns only once the app's connection has closed. The cleanup that `startApp` registers calls it again, which does nothing.
**Disclosures**
- Unverified: a hold-up that ends in the few microseconds between smallwebwaf passing the first bytes to the app and asking the client for more, or one that stalls only the app's reading of a request it was already sent, can still make the case fail.
Model: opus-5-5
In the cases where the app reads and the client stops sending halfway,
smallwebwaf waits on the client only once it has passed the first bytes
of the body to the app. A test process held up for the whole 300 ms
timeout before then rightly gets 504, as SPEC.md asks, so the test was
wrong to expect 408 every time.
The app in those cases now records whether it received any of the body.
Once the app has finished with the request, the case expects 408 and its
log line if it did, and 504 and its log line if not.
Model: opus-5-5
clawbot
changed title from Explain when TestRequestTimeouts rightly gets 504 for a stopped client to TestRequestTimeouts expects 504 when none of the body reached the app2026-10-04 05:27:27 +02:00
Reworked per the decision on #49 (comment): in the two cases where the client stops sending halfway, the app now records whether it received any of the body, and once it has finished with the request the case expects 408 and its log line if it did, 504 and its log line if not.
The long test comment is cut to a short one at that check; the PR body now describes the change and drops the owner's-call disclosure.
Model: opus-5-5
Reworked per the decision on https://git.eeqj.de/sneak/smallwebwaf/issues/49#issuecomment-119782: in the two cases where the client stops sending halfway, the app now records whether it received any of the body, and once it has finished with the request the case expects `408` and its log line if it did, `504` and its log line if not.
The long test comment is cut to a short one at that check; the PR body now describes the change and drops the owner's-call disclosure.
Model: opus-5-5
Review passed.
Judgement call: the two remaining failures the PR body discloses (smallwebwaf answering 504 just after the first bytes reached the app, and the app not yet having read the request when the test closes it) each need a hold-up that begins within a few microseconds, much narrower than the original failure, so they are accepted.
Model: opus-5-5
Review passed.
Judgement call: the two remaining failures the PR body discloses (smallwebwaf answering `504` just after the first bytes reached the app, and the app not yet having read the request when the test closes it) each need a hold-up that begins within a few microseconds, much narrower than the original failure, so they are accepted.
Model: opus-5-5
clawbot
merged commit 6bd5f620f6 into next2026-10-04 06:09:23 +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 #49.
Cause. In the two cases where the app reads and the client stops sending halfway, smallwebwaf waits on the client only once it has passed the first bytes of the body to the app; until then it is waiting on the app, and
SPEC.mdasks for504. A test process held up for the whole 300 ms timeout before that point therefore rightly gets504, and the test was wrong to expect408every time.Change. The app in those cases records whether it received any of the body. Once the app has finished with the request, the case expects
408and its log line if it did, and504and its log line if not. No change to smallwebwaf itself.Not in the diff.
app.Close()is what keeps the test from reading the app's record too early: it returns only once the app's connection has closed. The cleanup thatstartAppregisters calls it again, which does nothing.Disclosures
Model: opus-5-5
23df4310f8to7da6e147efExplain when TestRequestTimeouts rightly gets 504 for a stopped clientto TestRequestTimeouts expects 504 when none of the body reached the appReworked per the decision on #49 (comment): in the two cases where the client stops sending halfway, the app now records whether it received any of the body, and once it has finished with the request the case expects
408and its log line if it did,504and its log line if not.The long test comment is cut to a short one at that check; the PR body now describes the change and drops the owner's-call disclosure.
Model: opus-5-5
Review passed.
Judgement call: the two remaining failures the PR body discloses (smallwebwaf answering
504just after the first bytes reached the app, and the app not yet having read the request when the test closes it) each need a hold-up that begins within a few microseconds, much narrower than the original failure, so they are accepted.Model: opus-5-5