Where: internal/imageprocessor/imageprocessor.go, the encoder settings webpEffort (4), avifEffort (1) and JPEG XL at libvips' default effort; found by the review of #271.
What is wrong: at the input and output limits (8192x8192), an image with an alpha channel takes about 63 s to save as WebP, 110 s as AVIF and 96 s as JPEG XL on one libvips thread, as pixad runs it (measured for #271 with the runtime image's libvips on random pixels; without alpha 44, 53 and 28 s). The default downstream_timeout is 60 s, so such an output is never delivered, yet its transcode holds a processing slot to the end.
How it fails: an outsider requests a few large outputs with alpha, at distinct sizes, from an allowlisted host or with any signed or encrypted URL that allows a large size. Each keeps a slot busy for up to two minutes and answers no one; with every slot busy, other cache misses answer 503 after their wait. A legitimate request for such an output always times out.
Severity: medium (a denial of service: CLAUDE.md puts these at the top of TODO.md).
Plan:
Lower the WebP and JPEG XL effort until their worst case (alpha, 8192x8192, one thread) is under 40 s, leaving the rest of downstream_timeout for fetching, decoding and resizing; the comment on each setting gives the measured times.
AVIF is already at the lowest effort govips can set. If it cannot be brought under 40 s, an AVIF output with more pixels than fit in 40 s is refused with 400 before decoding work starts, like the other sizes that are too large, and README.md gives the limit.
README.md "Routes" gives the new worst case per format.
Definition of done:
No output format's worst case at the limits is above 40 s on one thread, or the output is refused up front; the numbers are measured and stated.
Test first for any new refusal; make check green.
Model: opus-5-5
Where: `internal/imageprocessor/imageprocessor.go`, the encoder settings `webpEffort` (4), `avifEffort` (1) and JPEG XL at libvips' default effort; found by the review of https://git.eeqj.de/sneak/pixa/pulls/271.
What is wrong: at the input and output limits (8192x8192), an image with an alpha channel takes about 63 s to save as WebP, 110 s as AVIF and 96 s as JPEG XL on one libvips thread, as pixad runs it (measured for https://git.eeqj.de/sneak/pixa/pulls/271 with the runtime image's libvips on random pixels; without alpha 44, 53 and 28 s). The default `downstream_timeout` is 60 s, so such an output is never delivered, yet its transcode holds a processing slot to the end.
How it fails: an outsider requests a few large outputs with alpha, at distinct sizes, from an allowlisted host or with any signed or encrypted URL that allows a large size. Each keeps a slot busy for up to two minutes and answers no one; with every slot busy, other cache misses answer 503 after their wait. A legitimate request for such an output always times out.
Severity: medium (a denial of service: `CLAUDE.md` puts these at the top of `TODO.md`).
Plan:
- Lower the WebP and JPEG XL effort until their worst case (alpha, 8192x8192, one thread) is under 40 s, leaving the rest of `downstream_timeout` for fetching, decoding and resizing; the comment on each setting gives the measured times.
- AVIF is already at the lowest effort govips can set. If it cannot be brought under 40 s, an AVIF output with more pixels than fit in 40 s is refused with 400 before decoding work starts, like the other sizes that are too large, and `README.md` gives the limit.
- `README.md` "Routes" gives the new worst case per format.
Definition of done:
1. No output format's worst case at the limits is above 40 s on one thread, or the output is refused up front; the numbers are measured and stated.
2. Test first for any new refusal; `make check` green.
Model: opus-5-5
clawbot
self-assigned this 2026-10-15 09:44:31 +02:00
Built in #278: WebP is saved at effort 2 and JPEG XL at effort 4, and an AVIF output of more than 16,777,216 pixels (4096x4096) is refused with 400 before anything is decoded. The comments on the settings and "Routes" in README.md give the measured times.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/pixa/pulls/278: WebP is saved at effort 2 and JPEG XL at effort 4, and an AVIF output of more than 16,777,216 pixels (4096x4096) is refused with 400 before anything is decoded. The comments on the settings and "Routes" in `README.md` give the measured times.
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.
Where:
internal/imageprocessor/imageprocessor.go, the encoder settingswebpEffort(4),avifEffort(1) and JPEG XL at libvips' default effort; found by the review of #271.What is wrong: at the input and output limits (8192x8192), an image with an alpha channel takes about 63 s to save as WebP, 110 s as AVIF and 96 s as JPEG XL on one libvips thread, as pixad runs it (measured for #271 with the runtime image's libvips on random pixels; without alpha 44, 53 and 28 s). The default
downstream_timeoutis 60 s, so such an output is never delivered, yet its transcode holds a processing slot to the end.How it fails: an outsider requests a few large outputs with alpha, at distinct sizes, from an allowlisted host or with any signed or encrypted URL that allows a large size. Each keeps a slot busy for up to two minutes and answers no one; with every slot busy, other cache misses answer 503 after their wait. A legitimate request for such an output always times out.
Severity: medium (a denial of service:
CLAUDE.mdputs these at the top ofTODO.md).Plan:
downstream_timeoutfor fetching, decoding and resizing; the comment on each setting gives the measured times.README.mdgives the limit.README.md"Routes" gives the new worst case per format.Definition of done:
make checkgreen.Model: opus-5-5
Built in #278: WebP is saved at effort 2 and JPEG XL at effort 4, and an AVIF output of more than 16,777,216 pixels (4096x4096) is refused with 400 before anything is decoded. The comments on the settings and "Routes" in
README.mdgive the measured times.Model: opus-5-5