Retry with backoff when a torrent completes with zero files - #394
Open
BasterdOperator wants to merge 1 commit into
Open
BasterdOperator wants to merge 1 commit into
BasterdOperator wants to merge 1 commit into
Conversation
Some debrid providers (Premiumize in particular) can flip a transfer's status to "finished" before the file's actual download link has been generated on their side. This is most noticeable for content that's already cached and completes in well under a second - the very first status check right after submission can race that window and see zero files, even though the provider confirms a valid link for the same file moments later. Today this permanently fails the download with "no valid download links available", for torrents that were, paradoxically, the fastest and most available to fetch. Observed with Premiumize on already-cached single-file torrents (software ISOs/installers): the transfer flips to "finished" ~1s after submission, filesForTransfer sees no link yet, and processTorrentDownload gives up immediately - while a manual query of the provider's item details a few seconds later shows the file fully ready with a working link. This adds a short, bounded retry (5 attempts, 2s/4s/8s/16s/16s backoff, ~30s total) that re-fetches the torrent from its active provider when GetActiveFiles() is empty, before giving up. Caveat: I don't have a Go toolchain available in the environment I wrote this in, so this has not been compiled or run - only reviewed by hand against the current types (ProviderEntry, ProviderFile, storage.File, debrid/types.Torrent/File) and the existing GetActiveProvider/ProviderClient/GetTorrent call sites elsewhere in the codebase. Please build/test before merging.
BasterdOperator
force-pushed
the
fix/instant-cache-empty-files
branch
from
August 17, 2026 16:56
1e1bd22 to
283402c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a short, bounded retry (5 attempts, 2s/4s/8s/16s/16s backoff, ~30s total)
in
processTorrentDownloadthat re-fetches the torrent from its active debridprovider when
entry.GetActiveFiles()comes back empty, before giving up with"no valid download links available".
Why
Some debrid providers (Premiumize in particular) can flip a transfer's status
to "finished" before the file's actual download link has been generated on
their side. This is most noticeable for content that's already cached and
completes in well under a second - the very first status check right after
submission can race that window and see zero files, even though the provider
confirms a valid link for the same file moments later.
Observed with Premiumize on already-cached single-file torrents (software
ISOs/installers). Example from my own logs:
Submitted-to-failed in ~3 seconds. A manual
GET /api/item/detailsagainstPremiumize's API for the same file a few minutes later (for a different,
similarly-affected torrent) returned a fully populated
link/directlink,virus_scan: "ok", correct size - i.e. genuinely ready, just not yet at themoment
processTorrentDownloadlooked.Today this fails permanently and needs a manual re-add (which, for a torrent
already cached provider-side, just re-submits the same infohash and usually
works immediately, confirming it's a timing issue and not a bad source). The
existing repair worker can also catch this in the background if
source: managedis configured, but that's a several-minutes-later mitigation, not afix for the immediate failure on first grab from an *arr.
Caveat
I don't have a Go toolchain available in the environment I wrote this in, so
this has not been compiled or run. I reviewed it by hand against the
current type definitions (
ProviderEntry,ProviderFile,storage.File,debrid/types.Torrent/File) and existing call sites forGetActiveProvider/ProviderClient/GetTorrentelsewhere in the codebase,but please build and test before merging - happy to fix up anything that
doesn't compile or behaves differently than intended.
Also open to a different shape entirely (e.g. hooking into the existing
repair/
RunChecksmachinery instead of a local retry loop) if that fits thecodebase's direction better - I went with the smallest, most self-contained
change I could reason about without a build.