gronod
7690d959b3
CI / Security audit (push) Successful in 1m52s
Docs Check / Markdown lint (push) Successful in 1m37s
Build and Push Docker Image / build (push) Successful in 2m2s
Licence Check / Licence compatibility and copyright header verification (push) Failing after 2m33s
CI / Swagger Validation & Coverage (push) Successful in 3m17s
Docs Check / Mermaid diagram parse check (push) Successful in 3m31s
CI / Tests & coverage (push) Successful in 4m5s
Fixes the root cause of the regression from v1.7.16. The v1.7.16 fix correctly cast arrQueueId to String, but the lookup was performed against downloadClientRegistry.getAllDownloads() which returns raw download client data (qBittorrent, SABnzbd, etc.) that never has arrQueueId populated. The fix now looks up the queue record directly from the Sonarr/Radarr queue cache where record.id is the numeric queue ID, using String() casting on both sides to handle the DOM-dataset (string) vs API response (number) type difference. Resolves Gitea Issue #48 Closes #48
47 lines
1.8 KiB
Plaintext
47 lines
1.8 KiB
Plaintext
## Summary
|
|
|
|
The "Blocklist and search" feature is broken for all users. Clicking the blocklist button on a download (e.g. the film "Project Hail Mary", `arrQueueId: 905000340`, `arrType: radarr`) consistently returns a `403 Download not found or permission denied` error.
|
|
|
|
## Root Cause
|
|
|
|
The server-side lookup in `server/routes/dashboard.js` uses strict equality (`===`) to find the matching download:
|
|
|
|
```js
|
|
const download = allDownloads.find(d => d.arrQueueId === arrQueueId && d.arrType === arrType);
|
|
```
|
|
|
|
- `d.arrQueueId` is populated from the Radarr/Sonarr queue API response as a **number** (e.g. `905000340`).
|
|
- `arrQueueId` from `req.body` originates from the client SPA via a DOM `dataset` attribute, which is always a **string** (e.g. `"905000340"`).
|
|
- Due to the type mismatch, `905000340 === "905000340"` evaluates to `false`, so the lookup always fails and returns `403`.
|
|
|
|
## Evidence
|
|
|
|
Server log (live environment, `2026-05-24`):
|
|
|
|
```
|
|
[Blocklist] Download not found: { arrQueueId: 905000340, arrType: 'radarr' }
|
|
```
|
|
|
|
Client log confirms user clicked blocklist at `21:01:19`, `21:01:32`, and `21:02:35`.
|
|
|
|
## Steps to Reproduce
|
|
|
|
1. Open the dashboard on a Radarr or Sonarr download with a pending queue entry.
|
|
2. Click the "Blocklist and search" button.
|
|
3. The action silently fails; the download is not removed and no re-search is triggered.
|
|
4. Server logs show `[Blocklist] Download not found`.
|
|
|
|
## Proposed Fix
|
|
|
|
Cast both sides of the comparison to `String` before comparing:
|
|
|
|
```js
|
|
const download = allDownloads.find(d => d.arrQueueId != null && String(d.arrQueueId) === String(arrQueueId) && d.arrType === arrType);
|
|
```
|
|
|
|
This fix will be released in version `1.7.16`.
|
|
|
|
## Severity
|
|
|
|
**High** — The blocklist-and-search feature is completely non-functional for all users. There is no workaround within the UI.
|