rays/ipodderx-rs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Answer status on the socket instead of queuing it behind the worker

Browse Source 
The worker runs one job at a time, and status was one of its jobs, so the
Docker healthcheck waited behind the startup scan (54 seconds of it after
the last deploy) and timed out at 5. Any scan or download longer than
three probes would have had a working daemon marked unhealthy. The socket
now answers status straight away; everything else still queues. A test
fills the queue and checks status comes back anyway.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TAC7sLVqfKmY6rsTLXzNgk
This commit is contained in:
Ray Slakinski
2026-09-12 14:19:00 +00:00
parent b94a74ef15
commit 1698cf8d1e
6 changed files with 84 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/architecture.md
View File

@@ -87,7 +87,8 @@ printf '{"cmd":"fetch","force":true}\n' | socat - UNIX-CONNECT:$XDG_RUNTIME_DIR/
**Events** — `feed_start`, `feed_skip`, `feed_done`, `feed_error`, `progress`, `download_done`,
`download_error`, `torrent_deferred`, `reaped`, `reap_done`, `scan_done`, `status`, `error`.
`scan_done`, `reap_done` and `status` are terminal: a client that asked for work stops reading
there.
there. Commands run one at a time, in the order they arrive, except `status`: the socket answers it
straight away, so the Docker healthcheck is never left waiting behind a scan or a download.
Progress carries the enclosure id, without which a UI cannot tell one download from another and
ends up animating every pending row. It is throttled to whole percents. The stream is a broadcast,

16
docs/history.md
View File

@@ -6,6 +6,22 @@ reasoning lives. New write-ups go at the top.
See [README.md](../README.md) for what the thing is.
## 2026-09-12 — Healthy while busy
After a deploy the container sat at "starting" for a minute, and Docker's health log showed two
`ipx status` probes exceeding their 5-second timeout. The daemon's own log explained it. The first
scan after the start fetched 23 feeds, from 14:10:41 to 14:11:35, and both probes' `status`
commands waited in the job queue behind it; they were answered together at 14:11:35, straight after
`scan_done`. The worker runs one job at a time and `status` was one of its jobs, so any scan or
download longer than about a minute and a half, three 30-second probes, would have had Docker call
a working daemon unhealthy.
The socket now answers `status` itself, from two short queries, and only real work goes through the
queue. The trade is that healthy now means the daemon answers on its socket and can read its
database; a worker stuck on one job would still pass. Asking a daemon that downloads hour-long
podcasts to be idle within five seconds was never a fair test of whether it was alive. A test holds
the queue full and checks `status` still comes back.
## 2026-09-12 — Signing in through Authentik, for real
Ray could not get Authentik's sign-in to reach ipx, following `docs/sso.md`, which had been written