From f0b67596c73a639f28accb585a835c3f1382035e Mon Sep 17 00:00:00 2001 From: clawbot <35+clawbot@noreply.example.org> Date: Tue, 29 Sep 2026 08:03:29 +0000 Subject: [PATCH] Say downstream_timeout covers the connection and processing waits (closes #64) The waits of up to 10 seconds for an upstream connection and for a processing slot run inside downstream_timeout, and a request whose downstream_timeout ends during one gets 500, not 503. The docs now say so and advise keeping downstream_timeout longer than upstream_fetch_timeout plus 20 seconds. Model: opus-5-5 --- README.md | 12 +++++++----- config.example.yml | 11 +++++++---- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index c05372c..001d863 100644 --- a/README.md +++ b/README.md @@ -288,8 +288,9 @@ Key settings in more detail: bytes; default `52428800` (50 MiB). It also limits the image data pixa decodes - `downstream_timeout` — time allowed for answering one client request, as a - duration; default `60s`. The upstream fetch counts toward it, so keep it - longer than `upstream_fetch_timeout` + duration; default `60s`. The upstream fetch counts toward it, and so do the + waits for an upstream connection and for a processing slot (up to 10 seconds + each), so keep it longer than `upstream_fetch_timeout` plus 20 seconds - `signing_key` — HMAC secret for URL signatures - `cache_max_bytes` — disk cache size limit in bytes; `0` disables the disk cache entirely; omitted defaults to 75% of the free space on @@ -298,12 +299,13 @@ Key settings in more detail: hosts together, on top of `upstream_connections_per_host`; default `64`. A fetch holds its connection until its image has been processed. A fetch that finds all of them in use waits up to 10 seconds for one to free up; if none - does, the request is answered 503 with the error - `server busy, try again later` + does, and `downstream_timeout` has not ended first, the request is answered + 503 with the error `server busy, try again later` - `max_concurrent_processing` — the most images decoded and encoded at once; default the number of CPUs pixa can use (`GOMAXPROCS`), which follows a container's CPU limit. A request that finds all of them in use waits up to 10 - seconds for one to free up; if none does, it is answered 503 the same way + seconds for one to free up; if none does, and `downstream_timeout` has not + ended first, it is answered 503 the same way See `config.example.yml` for all options with defaults. diff --git a/config.example.yml b/config.example.yml index 36cf388..d64d77e 100644 --- a/config.example.yml +++ b/config.example.yml @@ -74,13 +74,14 @@ upstream_connections_per_host: 20 # Maximum concurrent connections to all upstream hosts together, on top of # the per-host limit (default: 64). A fetch holds its connection until its # image has been processed. A fetch that finds none free waits up to 10 -# seconds for one, and if none frees up the request is answered 503. +# seconds for one, and if none frees up the request is answered 503, unless +# downstream_timeout has ended first. upstream_connections: 64 # Maximum number of images decoded and encoded at once (default: the # number of CPUs pixa can use, which follows a container's CPU limit). A # request that finds none free waits up to 10 seconds for one, and if none -# frees up it is answered 503. +# frees up it is answered 503, unless downstream_timeout has ended first. # max_concurrent_processing: 4 # Time allowed for one fetch from an upstream host (default: 30s) @@ -90,8 +91,10 @@ upstream_fetch_timeout: 30s # (1 GiB) (default: 52428800, 50 MiB) upstream_max_response_size: 52428800 -# Time allowed for answering one client request, the upstream fetch -# included, so keep it longer than upstream_fetch_timeout (default: 60s) +# Time allowed for answering one client request (default: 60s). The +# upstream fetch counts toward it, and so do the waits for an upstream +# connection and for a processing slot (up to 10 seconds each), so keep it +# longer than upstream_fetch_timeout plus 20 seconds. downstream_timeout: 60s # The origin a browser lets read pixa's responses, sent as the CORS