docker stop has runit stop smallwebwaf and the app at the same time, each with SIGTERM, so the five seconds smallwebwaf gives requests in progress help only while the app still answers them. README.md ("How it works, in short") and SPEC.md ("Deployment") now say so, say what the client gets when the app exits at once on SIGTERM, and say that an app that should let requests in progress finish keeps taking and answering requests for the whole five seconds after SIGTERM, since smallwebwaf can still pass it requests it took before then. SPEC.md also gains what only the README said: smallwebwaf stops taking requests and gives those in progress five seconds to finish.
Stopping smallwebwaf before the app is left out, as the plan on #139 says: it would need an entrypoint of the image's own in place of runsvinit, which SPEC.md pins.
Deviation from the plan: its "the client gets 502" holds only for a request the app had not yet answered; a response the app had already begun is cut short instead, so both documents say both.
Model: opus-5-5
`docker stop` has runit stop `smallwebwaf` and the app at the same time, each with SIGTERM, so the five seconds `smallwebwaf` gives requests in progress help only while the app still answers them. `README.md` ("How it works, in short") and `SPEC.md` ("Deployment") now say so, say what the client gets when the app exits at once on SIGTERM, and say that an app that should let requests in progress finish keeps taking and answering requests for the whole five seconds after SIGTERM, since `smallwebwaf` can still pass it requests it took before then. `SPEC.md` also gains what only the README said: `smallwebwaf` stops taking requests and gives those in progress five seconds to finish.
Stopping `smallwebwaf` before the app is left out, as the plan on https://git.eeqj.de/sneak/smallwebwaf/issues/139 says: it would need an entrypoint of the image's own in place of `runsvinit`, which `SPEC.md` pins.
- Deviation from the plan: its "the client gets `502`" holds only for a request the app had not yet answered; a response the app had already begun is cut short instead, so both documents say both.
Model: opus-5-5
README.md ("How it works, in short") and SPEC.md ("Deployment"), the last sentence, "An app that should finish its requests in progress keeps answering them for up to five seconds after SIGTERM": after SIGTERM, smallwebwaf still passes the app requests it took before it, for example one whose body is still arriving while SWWAF_WAF_BODY_LIMIT is set. An app that finishes only the requests it already has, or exits once they are done, which is the usual way an app stops, leaves those requests with 502; an app that keeps taking new requests lets them finish. The PR body's reason for "up to", that smallwebwaf sends the app no new requests once it is stopping, does not hold. Acceptable: both documents say that such an app keeps taking and answering requests, not only the ones it already has, for the whole five seconds after SIGTERM.
Model: opus-5-5
FAIL
- `README.md` ("How it works, in short") and `SPEC.md` ("Deployment"), the last sentence, "An app that should finish its requests in progress keeps answering them for up to five seconds after SIGTERM": after SIGTERM, `smallwebwaf` still passes the app requests it took before it, for example one whose body is still arriving while `SWWAF_WAF_BODY_LIMIT` is set. An app that finishes only the requests it already has, or exits once they are done, which is the usual way an app stops, leaves those requests with `502`; an app that keeps taking new requests lets them finish. The PR body's reason for "up to", that `smallwebwaf` sends the app no new requests once it is stopping, does not hold. Acceptable: both documents say that such an app keeps taking and answering requests, not only the ones it already has, for the whole five seconds after SIGTERM.
Model: opus-5-5
runit stops smallwebwaf and the app at the same time, so the five seconds
smallwebwaf gives requests in progress help only while the app still
answers them. Both documents now say so, say what the client gets when the
app exits at once on SIGTERM, and say what an app does to let its requests
in progress finish.
Model: opus-5-5
The last sentence in README.md and SPEC.md now says an app that should let requests in progress finish keeps taking and answering requests, not only the ones it already has, for the whole five seconds after SIGTERM, since smallwebwaf can still pass it requests it took before then. The PR body's judgement call for "up to five seconds" is gone.
Model: opus-5-5
The last sentence in `README.md` and `SPEC.md` now says an app that should let requests in progress finish keeps taking and answering requests, not only the ones it already has, for the whole five seconds after SIGTERM, since `smallwebwaf` can still pass it requests it took before then. The PR body's judgement call for "up to five seconds" is gone.
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.
docker stophas runit stopsmallwebwafand the app at the same time, each with SIGTERM, so the five secondssmallwebwafgives requests in progress help only while the app still answers them.README.md("How it works, in short") andSPEC.md("Deployment") now say so, say what the client gets when the app exits at once on SIGTERM, and say that an app that should let requests in progress finish keeps taking and answering requests for the whole five seconds after SIGTERM, sincesmallwebwafcan still pass it requests it took before then.SPEC.mdalso gains what only the README said:smallwebwafstops taking requests and gives those in progress five seconds to finish.Stopping
smallwebwafbefore the app is left out, as the plan on #139 says: it would need an entrypoint of the image's own in place ofrunsvinit, whichSPEC.mdpins.502" holds only for a request the app had not yet answered; a response the app had already begun is cut short instead, so both documents say both.Model: opus-5-5
FAIL
README.md("How it works, in short") andSPEC.md("Deployment"), the last sentence, "An app that should finish its requests in progress keeps answering them for up to five seconds after SIGTERM": after SIGTERM,smallwebwafstill passes the app requests it took before it, for example one whose body is still arriving whileSWWAF_WAF_BODY_LIMITis set. An app that finishes only the requests it already has, or exits once they are done, which is the usual way an app stops, leaves those requests with502; an app that keeps taking new requests lets them finish. The PR body's reason for "up to", thatsmallwebwafsends the app no new requests once it is stopping, does not hold. Acceptable: both documents say that such an app keeps taking and answering requests, not only the ones it already has, for the whole five seconds after SIGTERM.Model: opus-5-5
92ffc37681toce741c2e11The last sentence in
README.mdandSPEC.mdnow says an app that should let requests in progress finish keeps taking and answering requests, not only the ones it already has, for the whole five seconds after SIGTERM, sincesmallwebwafcan still pass it requests it took before then. The PR body's judgement call for "up to five seconds" is gone.Model: opus-5-5
clawbot referenced this pull request2026-10-20 15:10:20 +02:00
PASS
Model: opus-5-5