AllDebrid statusCode 7 (No peer after 30 minutes) treated as permanent error with no retry

[flippz]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Current Behavior

When a torrent is submitted to the AllDebrid provider and AllDebrid reports statusCode: 7 ("No peer after 30 minutes"), Decypharr immediately treats this as a permanent, terminal failure: it reports the download as errored to the Arr app and deletes the magnet from AllDebrid on the very first status check that observes this code. There is no retry/backoff before giving up.

This happens even when the underlying torrent clearly has healthy seeders (confirmed via the source tracker directly), and manually re-adding the exact same magnet to AllDebrid afterward resolves/completes in seconds. This suggests AllDebrid's "no peer after 30 minutes" status is often transient (e.g. a temporary peer/swarm connectivity hiccup specific to AllDebrid's infrastructure, not a genuinely dead torrent), but Decypharr never gives it a second chance.

Root cause appears to be in pkg/debrid/providers/alldebrid/alldebrid.go:

func getAlldebridStatus(statusCode int) types.TorrentStatus {
	switch {
	case statusCode == 4:
		return types.TorrentStatusDownloaded
	case statusCode >= 0 && statusCode <= 3:
		return types.TorrentStatusDownloading
	default:
		return types.TorrentStatusError
	}
}

Every AllDebrid status code outside 0-4 (this includes at least 7 "no peer after 30 minutes", 10 "download took more than 3 days", 11 "expired - files removed", and 15 "file not available - no peer") is collapsed into the same TorrentStatusError, with no distinction between "transient, worth retrying" and "permanently dead." CheckStatus() then returns this error on the very first read:

func (ad *AllDebrid) CheckStatus(torrent *types.Torrent) (*types.Torrent, error) {
	for {
		err := ad.UpdateTorrent(torrent)
		if err != nil || torrent == nil {
			return torrent, err
		}
		switch torrent.Status {
		case types.TorrentStatusDownloaded:
			return torrent, nil
		case types.TorrentStatusDownloading:
			...
		case types.TorrentStatusError:
			return torrent, fmt.Errorf("torrent: %s has error", torrent.Name)
		default:
			return torrent, fmt.Errorf("torrent: %s has error", torrent.Name)
		}
	}
}

This is inconsistent with the RealDebrid provider's handling, which treats several in-progress states as retryable rather than terminal, and which I never saw this same issue on before switching to AllDebrid:

// pkg/debrid/providers/realdebrid/realdebrid.go
func getStatus(status string) types.TorrentStatus {
	switch status {
	case "downloading", "magnet_conversion", "queued", "compressing", "uploading", "waiting_files_selection":
		return types.TorrentStatusDownloading
	case "downloaded":
		return types.TorrentStatusDownloaded
	default:
		return types.TorrentStatusError
	}
}

RealDebrid's CheckStatus() also actually loops (sleeping and re-polling) on these in-progress statuses instead of failing on the first check.

Expected Behavior

AllDebrid status code 7 ("No peer after 30 minutes") should not be treated as an immediate, final error. At minimum, Decypharr should retry the status check / re-submit the magnet a small number of times (with backoff) before giving up and deleting it, similar to how transient states are handled for RealDebrid. Ideally, status codes that represent genuinely terminal states (10 "download took more than 3 days", 11 "expired - files removed") should be distinguished from status 7, which appears to frequently be transient.

Steps To Reproduce

1. Configure Decypharr with AllDebrid as the debrid provider.
2. Grab a torrent via Sonarr/Radarr from a tracker with confirmed healthy seeders (verified directly on the tracker, not just via Decypharr/AllDebrid).
3. Occasionally, AllDebrid will report statusCode: 7 ("No peer after 30 minutes") for the magnet, despite the torrent having seeders.
4. Observe that Decypharr immediately reports the download as failed/errored and deletes the magnet from AllDebrid (visible in Decypharr's logs as an error="torrent: X has error" line for the item, followed by a Torrent <id> deleted from AD line, with no retry in between).
5. Manually re-add the exact same magnet/torrent directly via the AllDebrid web UI immediately after - it frequently completes within seconds, confirming the torrent was not actually dead.

Environment

• OS: Linux (Proxmox LXC, Docker)
• Version: v2.3.1
• Docker Install: Yes
• Browser: N/A (backend behavior, not UI)

What branch are you running?

Main/Latest

Trace Logs

Have debug-level logs showing the failure sequence (submission → statusCode 7 → error → delete from AD) for a specific magnet, but not trace-level logs, since log_level was set to debug at the time. Happy to reproduce with trace logging enabled if that's required to move this forward - let me know and I'll attach a full trace log for a fresh occurrence.