Answer image requests with 503 in maintenance mode (closes #71)
check / check (push) Successful in 13s
check / check (push) Successful in 13s
maintenance_mode was only reported by the health check; every request was still served. One middleware in routes.go, applied to /v1/image/ and /v1/e/ only, now answers them with 503, a Retry-After of MaintenanceRetryAfterSeconds and the JSON error body while it is on. It calls Server.MaintenanceMode(), which had no caller. The health check stays 200 and reports maintenance_mode: the image's Docker HEALTHCHECK requests it, a 503 there would make the container unhealthy, and upaas marks a deploy failed when its container is unhealthy. The login and URL generator pages and /metrics keep working. Documented in README.md and config.example.yml. Model: opus-5-5
This commit was merged in pull request #154.
This commit is contained in:
@@ -29,6 +29,14 @@ P2: security: referer blacklist
|
||||
|
||||
# Completed Steps
|
||||
|
||||
- 2026-09-29 maintenance mode refuses image requests (closes #71): while
|
||||
`maintenance_mode` is on, `/v1/image/` and `/v1/e/` answer 503 with a
|
||||
`Retry-After` header and the JSON error body, from one middleware in
|
||||
`internal/server/routes.go`; the health check stays 200 and reports
|
||||
`maintenance_mode`, as the image's Docker `HEALTHCHECK` requests it and upaas
|
||||
marks a deploy failed when its container is unhealthy; the login and URL
|
||||
generator pages and `/metrics` keep working; documented in `README.md` and
|
||||
`config.example.yml`.
|
||||
- 2026-09-29 bound concurrent image processing and upstream fetches (closes
|
||||
#64): `max_concurrent_processing` (default the number of CPUs pixa can use)
|
||||
limits the images decoded and encoded at once, and `upstream_connections`
|
||||
|
||||
Reference in New Issue
Block a user