Tests: the daemon's start, shutdown and the CLI talking to it #400

New Issue

rays · 2026-11-06T19:51:42-08:00

rays commented

2026-11-06 19:51:42 -08:00

daemon.rs is at 76% and cli.rs at 41% of their lines. Untested: a second daemon refused while one listens on the socket (line 57; CLAUDE.md, two daemons fighting over a database); the first start writing a web token and bind (start_web, 247-259); a SIGTERM during a job abandoning it (173); until_stopped and until_next_scan; and in the CLI, run and ipc.rs's proxy (a command forwarded to a running daemon) and human (its output in words). These are what production's start and ipx status depend on.

Tests to add:

starting a second daemon on the same socket fails with "a daemon is already listening", and the first keeps serving
a first start with an empty token writes one into the config and serves with it
SIGTERM during a long download stops within the grace period and leaves the download to resume (requeued at the next start)
ipx status, ipx fetch <feed>, ipx list with a daemon running go through the socket and print as before; without one, --local does the work itself
the start trace (start, #374) has its steps

Seen with the coverage of both suites merged line by line (cargo: sh scripts/coverage.sh, browser: sh scripts/coverage.sh api; reports in target/coverage/cargo, api and page; #390, #394), as of 2026-11-07. A test added here shows in Grafana's Coverage row at the next run.

daemon.rs is at 76% and cli.rs at 41% of their lines. Untested: a second daemon refused while one listens on the socket (line 57; CLAUDE.md, two daemons fighting over a database); the first start writing a web token and bind (`start_web`, 247-259); a SIGTERM during a job abandoning it (173); `until_stopped` and `until_next_scan`; and in the CLI, `run` and ipc.rs's `proxy` (a command forwarded to a running daemon) and `human` (its output in words). These are what production's start and `ipx status` depend on. Tests to add: - starting a second daemon on the same socket fails with "a daemon is already listening", and the first keeps serving - a first start with an empty token writes one into the config and serves with it - SIGTERM during a long download stops within the grace period and leaves the download to resume (requeued at the next start) - `ipx status`, `ipx fetch <feed>`, `ipx list` with a daemon running go through the socket and print as before; without one, `--local` does the work itself - the start trace (`start`, #374) has its steps Seen with the coverage of both suites merged line by line (cargo: `sh scripts/coverage.sh`, browser: `sh scripts/coverage.sh api`; reports in target/coverage/cargo, api and page; #390, #394), as of 2026-11-07. A test added here shows in Grafana's Coverage row at the next run.

rays added the enhancement label 2026-11-06 19:51:42 -08:00

rays referenced this issue

2026-11-06 20:20:04 -08:00

Tests: torrents #397

rays referenced this issue

2026-11-06 20:24:01 -08:00

A download stopped by a restart waits for its feed's next check #410

rays commented

2026-11-06 20:24:59 -08:00

Tests added in 2db42b5. crates/ipx/tests/daemon.rs runs the built binary as production does (scratch config, SQLite, a local feed whose episode trickles): ipx status through the socket and with --local; a first start writes a token, keeps it out of the log, and it signs in; a second daemon is refused with 'a daemon is already listening' and the first keeps serving; SIGTERM mid-download exits in under 5 s, logs the abandoned job, removes the socket and leaves the episode queued; a restart is clean; ipx status without a daemon works alone. daemon.rs: until_next_scan's 30 s floor and 10 minute ceiling. Found: the abandoned download is not taken again at the next start, only at its feed's next check (#410). Not done: the start trace's steps (needs a trace exporter to read them from), and ipx fetch through the socket, which waits for the whole scan and so for the slow episode.

Tests added in 2db42b5. crates/ipx/tests/daemon.rs runs the built binary as production does (scratch config, SQLite, a local feed whose episode trickles): ipx status through the socket and with --local; a first start writes a token, keeps it out of the log, and it signs in; a second daemon is refused with 'a daemon is already listening' and the first keeps serving; SIGTERM mid-download exits in under 5 s, logs the abandoned job, removes the socket and leaves the episode queued; a restart is clean; ipx status without a daemon works alone. daemon.rs: until_next_scan's 30 s floor and 10 minute ceiling. Found: the abandoned download is not taken again at the next start, only at its feed's next check (#410). Not done: the start trace's steps (needs a trace exporter to read them from), and ipx fetch through the socket, which waits for the whole scan and so for the slow episode.

rays referenced this issue from a commit

2026-11-06 20:24:59 -08:00

Tests for the daemon's start, shutdown and CLI (#400)

rays closed this issue

2026-11-06 20:25:00 -08:00

rays referenced this issue from a commit

2026-11-06 20:50:40 -08:00

A download a restart stopped is taken up again at the start (#410)

rays referenced this issue from a commit

2026-11-06 21:55:44 -08:00

The daemon test stops its daemons when an assertion fails (#400)

Sign in to join this conversation.