Feature: optionally delete upstream TorBox task on job removal (opt-in)

[calmcacil]

Feature request: optionally delete the TorBox task when a job is removed

Problem

When Sonarr/Radarr (or a user) removes a torrent through the qBittorrent/SABnzbd API, TorBoxarr deletes its local job record but leaves the corresponding task alive in the TorBox account. Over time this accumulates orphaned entries in TorBox — the *arr apps consider the download gone, but it still occupies the TorBox library/queue and has to be pruned manually.

Proposal

Add an opt-in flag, TORBOXARR_UPSTREAM_REMOVE (default false), that makes a job removal also issue a delete against the TorBox API for the associated remote_id.

• Enabled: removing a torrent in the *arr app cleans up both sides (local payload + TorBox task).
• Disabled (default): behavior is unchanged — local-only removal, TorBox content retained.

Design sketch

• A DeleteTask(ctx, sourceType, remoteID) method on the TorBox Client interface, with an HTTP implementation calling the TorBox control endpoints (/api/torrents/controltorrent and /api/usenet/controlusenetdownload with {"operation":"delete", ...}).
• The remover worker checks the config flag; when set and a remote_id exists, it calls DeleteTask before local cleanup.
• Retryable errors bubble up so the job is retried; non-retryable errors log a warning and proceed with local cleanup (removal is never blocked by an upstream failure).
• Log/state messages distinguish "upstream torbox task deleted" from "torbox content retained".

Why opt-in

Some users deliberately keep content in TorBox after the *arr app has grabbed it (re-use, seeding credit, manual re-import). A flag respects both workflows and keeps the change non-breaking for existing deployments.

I have a working implementation and would be happy to open a PR if this direction sounds good.

[MrJoiny]

I had same idea while creating this project, but rejected it because i only had focus on usenet, but this makes a lot sense for torrents, because of the limit there.
Would love to see this as a PR.

Just a few things i'd like to have covered if possible and worth it in your opinion:

• Retry transient TorBox errors with backoff, but don’t let an upstream failure block local removal indefinitely.
• Handle queued jobs that have a queued_id but no remote_id, or clearly document that they are excluded.
• Encode the TorBox task IDs as numbers, as expected by the current API schema.
• Add tests for both torrent and Usenet removal, including removal while another worker is processing the job.
• Document the new setting in the README and .env.example.

[calmcacil]

Long-time usenet enjoyer myself too — I just picked up TorBox recently to backfill old anime more easily, since it's not always available from good usenet sources. Heads up: I've been using AI assistance to get this feature working the way I wanted, so happy to walk through any of the logic if anything looks off.

The torrent limits aren't a real concern for this feature from my side — I'm capped at 3 active downloads at a time (as I understand it). The actual motivation was just that my TorBox dashboard kept getting flooded with entries that had already been imported. I also noticed Sonarr would import successfully but never delete the local files, which is why I pushed #4.

I started with the recommended rdtclient and it was even spottier, but this project has worked flawlessly for me with the two PRs I sent, on a locally built image — so I figured I'd offer the cleanup as a PR too.

On your checklist: items 1, 2, and 5 were already handled by the time I picked this up. I've since rolled items 3 and 4 into my local feature branch as well, and it's been running without issues so far. Full disclosure, that branch is AI-assisted. I'll keep it in testing for a while longer before I open the PR.

The one thing I'm still missing is an easier way to add manual downloads — right now anything outside the *arr flow has to go through the qBittorrent API directly since there's no web UI. If you've got thoughts on that, I'd be interested to hear them.

[MrJoiny]

Glad this project works out for you and thank you for contributions to it.

I also started with rdtclient, but it did not work at all for me. So i created https://github.com/MrJoiny/torbox-auto-downloader which is a file based download client. On request i created this project with the knowledge from the last project. I am pretty happy with the current state of it.

Two things came to my mind:

• A simple api where a webui could connect to
• A simple standalone offline html that bridges between webui upload and qbit api endpoint of this project.

I have nothing against a web ui, but i don't think it would fit the current scope of this project.

I am not stuck on this opinion, open for any changes.
What is your thoughts on that?

[calmcacil]

I don't really feel like an API or WebUI is needed for this to work. The way I have it testing on my fork right now is just an add subcommand that uses the qBittorrent-compatible API the server already exposes. I also thought about using watchdir/<category>/file.torrent (or magnet.txt), but the subcommand felt simple enough on my end and I don't mind firing up ssh every now and then.

I just wanted a simple way to get it into Sonarr for old anime backfill, especially since sometimes it can be a PITA to let the *arrs find that stuff themselves.

So I just have it working with docker exec torboxarr torboxarr add --category sonarr --magnet "..."

[MrJoiny]

Yea true this looks good to me. I'll give it some more thoughts, but i think this is currently the simplest / best solution.

Feel free to create the PR whenever you are ready, everything looks good to me so far.

[calmcacil]

I’ve been working on this more recently and have run into a few frustrating issues, including what appear to be bugs originating upstream in TorBox. These include jobs getting stuck because of filename-length limitations, as well as jobs being queued upstream but never actually starting.

I may be able to submit fixes for some of these issues as PRs if that would be useful. Otherwise, I’m happy to continue maintaining the changes in my local branch.