SKYHOUSE.dev Journal

Why: A set of Fionna & Cake episodes kept re-appearing in rdt-client/TorBox no matter how many times they were deleted at every level — Damien had been fighting them for hours — and the churn was rate-limiting the whole TorBox account (HTTP 429 storms).

This was a freshly-built (last 2 days) Sonarr → rdt-client (TorBox backend) → library pipeline, and it had three intertwined faults. The acute symptom was the Fionna loop; underneath it were a self-defeating cleanup cron and a missing cached-only gate.

1. What was actually happening

The loop lived in layers below Sonarr. Sequence:

• Sonarr grabbed release after release (RSS + searches) and pushed magnets to rdt-client's qBittorrent-emulation API (POST /api/v2/torrents/add, category tv).
• rdt-client polls TorBox for every torrent every CheckInterval (was 5s). With a backlog of zombie rows this blew past TorBox's rate limit → 429 Too Many Requests → status never resolved → sends to the shim timed out at 100s.
• Sonarr saw each grab "fail" (even when rdt-client had accepted it), kept the episode "wanted", and grabbed again — instant duplicates.
• Even after the Fionna series was deleted from Sonarr, 12 Fionna rows persisted in rdt-client's own DB and 9 copies sat in the TorBox account; nothing issued a clean delete at the layer that owned them, so they lingered and re-processed.

2. Acute fix — purge Fionna at the owning layers

• Stopped rdtclient, backed up /home/rdtclient/db/rdtclient.db, deleted the 12 Fionna rows (Downloads + Torrents tables), restarted. Torrent-row edits to this DB do persist.
• Deleted the 9 Fionna torrents from the TorBox account via its API (POST /v1/api/torrents/controltorrent, operation: delete).
• Verified: 0 Fionna in rdt-client DB, 0 in TorBox, and no new Fionna adds after restart (Sonarr now logs No matching series and discards them).

3. Root-cause fix — the cleanup cron was holding the door open

/home/plex/bin/sonarr-queue-cleanup.sh (cron, every 5 min) was removing stuck completed/warning queue items with removeFromClient=false&blocklist=false — so dead releases were never blocklisted and were instantly re-grabbable, and the rdt-client torrents were left orphaned. In a debrid setup a cached grab imports within seconds, so anything still stuck after the cutoff is a dead/uncached/un-importable release.

• Action: changed the bulk-delete call to removeFromClient=true&blocklist=true&skipRedownload=true. Now stuck grabs are cleaned from the client and blocklisted, so Sonarr moves on to a different (ideally cached) release instead of re-grabbing the same dead one forever. This doubles as a soft cached-only filter.

4. rdt-client tuning

• Raised Provider:CheckInterval 5 → 10 to halve baseline TorBox polling. 429 pressure dropped from thousands/log to single digits.
• Confirmed Provider:AutoImport=False must stay off — if on, rdt-client re-imports every torrent in the TorBox account, recreating zombie rows.
• Left Provider:AutoDelete off on purpose: its exact trigger timing vs. Sonarr's import is risky (could delete a download before import). Revisit via the web UI if desired.

5. The real architectural gap: nothing enforces cached-only

The docs describe the TV rdt-client as "cache-only", but nothing actually gates it. Sonarr grabs uncached releases from the public trackers; TorBox then has to download them server-side (slow, consumes the 3 active slots) and they loop. OnlyDownloadAvailableFiles is file-level, not an add-time gate. A real fix needs a cache-checking layer between Prowlarr and the arrs; the fixed cron is only a soft mitigation. Flagged for follow-up.

Net effect: the Fionna loop is dead, the 429 storm is gone, and the cleanup cron now blocklists dead grabs instead of recycling them. The broader uncached-grab churn (Breaking Bad S04 etc.) will grind down via the fixed cron but still wants a proper cached-only gate.