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

Answer status to the client that asked, not everyone

Browse Source 
status is a terminal event. Broadcast, the healthcheck's answer ended any
ipx fetch that was watching a scan, which stopped reading at the next probe
while the scan carried on. It could not happen while status waited behind
the scan; answering it at once made it happen every 30 seconds. Each
connection's writer now takes private replies beside the broadcast, and
the test checks another client hears nothing.

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:27:42 +00:00
parent 1698cf8d1e
commit 2ff2074755
4 changed files with 33 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/architecture.md
View File

@@ -88,7 +88,8 @@ printf '{"cmd":"fetch","force":true}\n' | socat - UNIX-CONNECT:$XDG_RUNTIME_DIR/
`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. 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.
straight away, so the Docker healthcheck is never left waiting behind a scan or a download, and
answers only the client that asked, since `status` would end any other client's session.
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,

7
docs/history.md
View File

@@ -22,6 +22,13 @@ database; a worker stuck on one job would still pass. Asking a daemon that downl
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.
The first version broadcast the answer, as the queued one had been. Timing `status` during a forced
scan in production showed the catch: `status` is a terminal event, so the `ipx fetch` watching that
scan stopped reading at the first probe and printed the status line as its last, while the scan
carried on. When `status` waited behind the scan it could never arrive first, so this had never
shown. The answer now goes only to the client that asked, and the test checks that another client
hears nothing.
## 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