Repeated invalid grab payloads cause linear search delays

Is there an existing issue for this?

• I have searched the existing open and closed issues.

Current Behavior

When an indexer's search endpoint returns valid releases but its grab/download endpoint repeatedly returns an invalid payload, Radarr attempts every accepted release from that indexer in sequence. Each attempt is also subject to the indexer's rate limit, so a systemic grab-endpoint failure adds latency proportional to the number of accepted releases.

This was observed with Prowlarr-backed indexers on Radarr 6.4.2.10590. A reverse-proxy routing error caused every Prowlarr grab URL to return an Authentik HTML response instead of an NZB or torrent. Three concurrent movie searches took 13:18, 13:35, and 13:49 and produced no usable download; the incident logs contained 100 invalid-NZB failures and 24 invalid-torrent failures. Correcting the proxy route fixed the upstream cause and subsequent searches completed in seconds.

The isolated trace reproduction uses one Newznab indexer returning four valid, accepted search results. Each result's download URL returns the same 76-byte HTML document with HTTP 200. Radarr makes all four grab attempts, waits about two seconds before each one, raises four InvalidNzbExceptions, and finishes with zero reports downloaded after 8.02 seconds.

This report is about the amplification of a repeated/systemic failure. It is not proposing that one invalid, deleted, or malformed release should disable an otherwise healthy indexer.

Expected Behavior

Radarr should bound repeated grab attempts from the same indexer during a search when consecutive responses provide strong evidence of a systemic invalid-payload failure, while continuing to tolerate an isolated bad release.

The exact safeguard is a design choice. Possible signals could include a small consecutive-failure threshold within the current search, identical invalid response bodies, an unexpected HTML/authentication response, or another narrow classification that does not treat one bad release as an indexer-wide failure. Other indexers should remain eligible.

Steps To Reproduce

1. Run Radarr 6.4.2.10590 with Trace logging enabled.
2. Configure a Newznab indexer whose capabilities and search endpoints return valid data.
3. Have a movie search return four releases that pass Radarr's download decisions.
4. Configure every release download URL from that indexer to return HTTP 200 with the same HTML document instead of an NZB.
5. Configure a Usenet Blackhole download client and run an interactive movie search.
6. Observe that Radarr accepts all four releases, then attempts each one sequentially. Each grab is delayed approximately two seconds by RateLimitService and fails validation with Unexpected root element. Expected 'nzb' found 'html'.
7. Observe the command complete after 8.02 seconds with 0 reports downloaded. Increasing the number of accepted results increases the delay linearly.

The same failure pattern can occur generically when:

• a reverse proxy or SSO layer returns a login/error page for all grab URLs;
• an indexer or aggregator returns the same API error document with HTTP 200 for every grab;
• a proxy/aggregator routes the search endpoint correctly but misroutes the download endpoint; or
• expired authentication consistently returns an HTML response.

In contrast, a single deleted or corrupt release is expected to fail without triggering an indexer-wide safeguard.

Environment

- OS: TrueNAS SCALE host / Alpine 3.24.1 container in the isolated reproduction
- Radarr: 6.4.2.10590
- Docker Install: Yes (`ghcr.io/home-operations/radarr:6.4.2.10590` for the isolated reproduction)
- Using Reverse Proxy: Yes in the observed incident; No in the isolated reproduction
- Browser: N/A
- Database: SQLite

What branch are you running?

Develop

Trace Logs? Not Optional

Sanitized full trace for the isolated reproduction: https://gist.github.com/EasyAsABC123/7a3129f307f56160cbe25ddc936d0bb5

Relevant sequence in the trace:

• 14:03:34.8: MoviesSearch starts; four releases are accepted.
• 14:03:34.8: first grab is delayed 1.979 seconds.
• 14:03:36.8, 14:03:38.8, 14:03:40.8, 14:03:42.8: four 76-byte HTTP 200 responses fail NZB validation because the root element is html.
• Between failures, the next release is immediately selected and delayed another 1.976-1.985 seconds.
• 14:03:42.8: search completes with zero reports after 00:00:08.0212438.

The reproduction was performed in disposable containers with a local mock Newznab endpoint. The API key was removed from the trace.

This issue is the trace-backed follow-up requested in https://github.com/Radarr/Radarr/pull/11665#issuecomment-5467563149.

Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.

• I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.