TorBox: /api/v2/torrents/add blocks HTTP response causing *arr timeout (cached and uncached)

[rsantamaria01]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Related: #204, #89, #270

Current Behavior

All *arrs (Sonarr, Radarr, etc.) timeout when submitting any torrent to
decypharr backed by TorBox. The /api/v2/torrents/add endpoint makes
synchronous TorBox API calls while holding the HTTP connection open.
The *arr's HTTP client fires its timeout before decypharr responds.

This happens regardless of the download_uncached setting:

• download_uncached=true: blocks while TorBox downloads the torrent
• download_uncached=false: blocks while TorBox checks cache status, then returns 400 — but the 400 itself arrives after a timeout-length delay

Error seen in Sonarr and Radarr:

NzbDrone.Core.Download.Clients.DownloadClientException:
Failed to connect to qBittorrent, please check your settings.
 ---> System.Net.WebException: Http request timed out
 ---> System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
 ---> System.Net.Sockets.SocketException (125): Operation canceled

Confirmed by timing the endpoint directly from inside the Sonarr container:

curl -m 5 -X POST http://decypharr:8282/api/v2/torrents/add \
  -d 'urls=magnet:?xt=urn:btih:<hash>&category=tv-sonarr'
# → HTTP 000 — no response within 5s; hangs indefinitely without -m

The qBittorrent WebAPI spec requires /api/v2/torrents/add to return Ok. immediately and process asynchronously. Blocking the response violates this contract and breaks all *arr download workflows.

PR #270 fixed an equivalent block for RealDebrid (infinite loop in CheckStatus). That PR notes TorBox was "unaffected" — but TorBox exhibits the same symptom via a different code path.

Expected Behavior

/api/v2/torrents/add returns Ok. immediately. TorBox submission and status polling happens asynchronously in the background.

Environment

- OS: Debian (Docker)
- Decypharr version: 2.3-stable (latest 2026-05-20)
- Debrid provider: TorBox
- *Arrs affected: Sonarr v4.0.17.2952, Radarr
- Docker Compose: v5.1.3

Trace Logs

2026-05-20 06:21:42 | INFO  | [torbox] Processing torrent Action=symlink Arr=tv-sonarr-anime Hash=c794... Name="[Tsundere-Raws] Aoashi - 03 VOSTFR" Provider=torbox
2026-05-20 06:23:24 | INFO  | [torbox] Processing torrent Action=symlink Arr=tv-sonarr-anime Hash=dda6... Name="[Tsundere-Raws] Aoashi - 03 VOSTFR" Provider=torbox
# ↑ decypharr loops polling torbox while Sonarr's connection is held open

Trace Logs have been provided as applicable

• I have read and followed the steps in the documentation link and provided the required trace logs

[pajammies]

Would this also be why my TorBox Dashboard ends up with multiple copies of the same requested media? Sonarr/Radarr send a torrent to Decypharr, but get a "failed to connect to qBittorrent" response, so keep re-sending?

Checking other Decypharr issues, this could be related to issue #76.

[0oAstro]

I reproduced this against TorBox and found one config-only cause/workaround that may help some setups.

In my case the endpoint was not blocked by TorBox itself: a direct createtorrent API call returned in ~0.4s. The timeout was Decypharr self-throttling behind its startup/background TorBox sync. This account had ~441 TorBox items, and the config had rate_limit: "55/hour", so initial sync consumed/starved the main provider limiter and POST /api/v2/torrents/add sat behind it until the *arr/curl timeout.

Changing only config + image made add return promptly:

{
  "debrids": [{
    "provider": "torbox",
    "rate_limit": "100/minute",
    "repair_rate_limit": "10/minute",
    "download_rate_limit": "30/minute",
    "workers": 1,
    "torrents_refresh_interval": "30m",
    "download_links_refresh_interval": "30m"
  }],
  "skip_pre_cache": true,
  "refresh_interval": "60s"
}

Also moved from v2.0 to latest (2.3-stable at test time).

After this, Decypharr initial sync completed in ~7s and the same POST /api/v2/torrents/add returned HTTP 200 in ~0.98s; TorBox cached/complete state followed ~1s later and the symlink was created.

This is not a full architectural fix for synchronous torrents/add, but it suggests one failure mode here is provider rate-limit starvation by background sync. A real fix might be to keep torrents/add off the same limiter/queue as bulk sync, or return qBittorrent-style immediately and continue TorBox status processing async.