Gandalf/sofarr
Public Access
0
0
Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases 59 Wiki Activity

BUG: Blocklist & Search fails with 400 Bad Request on season packs / multi-episode releases #44

New Issue
Closed
opened 2026-05-24 10:31:07 +01:00 by Gandalf · 2 comments
Gandalf commented 2026-05-24 10:31:07 +01:00
Owner
Copy Link
Copy Source

Problem:
The "Blocklist & Search" button on download cards fails with a "400 Bad Request (Missing required fields)" when clicked on any television release in Sonarr that represents a full season package or a multi-episode release.

Root Cause:

  1. In server/services/DownloadMatcher.js, when a download is matched with a Sonarr queue record, arrContentId is populated with sonarrMatch.episodeId || null.
  2. However, for multi-episode packs or full season grabs in Sonarr v3, the episodeId field is missing from the queue record payload (since the release is associated with multiple episodes). Instead, Sonarr provides an episodeIds array. As a result, arrContentId is normalized to null.
  3. When the user clicks the "Blocklist & Search" button in the UI, the frontend calls the POST /api/dashboard/blocklist-search endpoint. The request body includes arrContentId: null.
  4. The backend route validator in server/routes/dashboard.js strictly requires all fields including arrContentId to be truthy: 
    if (!arrQueueId || !arrType || !arrInstanceUrl || !arrContentId || !arrContentType) {
  return res.status(400).json({ error: 'Missing required fields' });
}
    Because arrContentId is null, this check fails and returns 400 Missing required fields, completely blocking the blocklist operation (even though queue removal itself does not require an episode ID).
  5. Furthermore, the search trigger logic in dashboard.js only handles single episode searches via { name: 'EpisodeSearch', episodeIds: [arrContentId] } and has no logic to handle episodeIds arrays or fallback searches (such as SeriesSearch or SeasonSearch).

Proposed Fix:

  1. Relax Backend Validation: Allow arrContentId to be optional or null for sonarr queue records to ensure the deletion and blocklist steps can still execute.
  2. Robust Search Triggers:
    • If episodeId is missing but episodeIds array is available on the matched record, pass the array of IDs to the frontend/backend.
    • Modify the dashboard.js re-search block to support EpisodeSearch with multiple IDs, or fall back to triggering a SeriesSearch command using the seriesId if no specific episode IDs are resolved.
Problem: The "Blocklist & Search" button on download cards fails with a "400 Bad Request (Missing required fields)" when clicked on any television release in Sonarr that represents a full season package or a multi-episode release. Root Cause: 1. In `server/services/DownloadMatcher.js`, when a download is matched with a Sonarr queue record, `arrContentId` is populated with `sonarrMatch.episodeId || null`. 2. However, for multi-episode packs or full season grabs in Sonarr v3, the `episodeId` field is missing from the queue record payload (since the release is associated with multiple episodes). Instead, Sonarr provides an `episodeIds` array. As a result, `arrContentId` is normalized to `null`. 3. When the user clicks the "Blocklist & Search" button in the UI, the frontend calls the `POST /api/dashboard/blocklist-search` endpoint. The request body includes `arrContentId: null`. 4. The backend route validator in `server/routes/dashboard.js` strictly requires all fields including `arrContentId` to be truthy: ```javascript if (!arrQueueId || !arrType || !arrInstanceUrl || !arrContentId || !arrContentType) { return res.status(400).json({ error: 'Missing required fields' }); } ``` Because `arrContentId` is `null`, this check fails and returns `400 Missing required fields`, completely blocking the blocklist operation (even though queue removal itself does not require an episode ID). 5. Furthermore, the search trigger logic in `dashboard.js` only handles single episode searches via `{ name: 'EpisodeSearch', episodeIds: [arrContentId] }` and has no logic to handle `episodeIds` arrays or fallback searches (such as `SeriesSearch` or `SeasonSearch`). Proposed Fix: 1. **Relax Backend Validation**: Allow `arrContentId` to be optional or null for `sonarr` queue records to ensure the deletion and blocklist steps can still execute. 2. **Robust Search Triggers**: - If `episodeId` is missing but `episodeIds` array is available on the matched record, pass the array of IDs to the frontend/backend. - Modify the `dashboard.js` re-search block to support `EpisodeSearch` with multiple IDs, or fall back to triggering a `SeriesSearch` command using the `seriesId` if no specific episode IDs are resolved.
Gandalf added the Kind/Bug
Priority
High
2
 labels 2026-05-24 10:31:07 +01:00
Gandalf commented 2026-05-24 10:41:12 +01:00
Author
Owner
Copy Link
Copy Source

I have investigated the blocklist & search failure reported in this issue and created a technical remediation plan:

Root Cause

For television grabs representing a full-season pack or multi-episode package in Sonarr, the episodeId property is absent (instead, it has an episodeIds array). This maps to a null value for arrContentId on the client download card. The /api/dashboard/blocklist-search route strictly requires all fields including arrContentId to be truthy, returning 400 Bad Request: Missing required fields and completely blocking the queue blocklist/removal action.

Remediation Plan

  1. Enrich Backend Match Data: Expose arrContentIds (sonarrMatch.episodeIds) and arrSeriesId (sonarrMatch.seriesId) from DownloadMatcher.js to the normalized download card object.
  2. Relax API Route Validation: Remove arrContentId from the mandatory request parameters check in server/routes/dashboard.js.
  3. Enhance Search Commands:
    • If a single arrContentId is provided, trigger EpisodeSearch for that single ID.
    • If an arrContentIds array is provided, trigger EpisodeSearch with that list of IDs.
    • If no specific episode IDs can be resolved but arrSeriesId is provided, fall back to triggering a series-wide SeriesSearch.
  4. Update Frontend & Documentation: Update the client payload, update the OpenAPI spec, and add integration tests covering single/multi/fallback searches.

Upon approval, I will execute this plan, merge to main, close this ticket referencing the resolving commit, and cut a new point release (v1.7.11).

I have investigated the blocklist & search failure reported in this issue and created a technical remediation plan: ### Root Cause For television grabs representing a full-season pack or multi-episode package in Sonarr, the `episodeId` property is absent (instead, it has an `episodeIds` array). This maps to a `null` value for `arrContentId` on the client download card. The `/api/dashboard/blocklist-search` route strictly requires all fields including `arrContentId` to be truthy, returning `400 Bad Request: Missing required fields` and completely blocking the queue blocklist/removal action. ### Remediation Plan 1. **Enrich Backend Match Data**: Expose `arrContentIds` (`sonarrMatch.episodeIds`) and `arrSeriesId` (`sonarrMatch.seriesId`) from `DownloadMatcher.js` to the normalized download card object. 2. **Relax API Route Validation**: Remove `arrContentId` from the mandatory request parameters check in `server/routes/dashboard.js`. 3. **Enhance Search Commands**: - If a single `arrContentId` is provided, trigger `EpisodeSearch` for that single ID. - If an `arrContentIds` array is provided, trigger `EpisodeSearch` with that list of IDs. - If no specific episode IDs can be resolved but `arrSeriesId` is provided, fall back to triggering a series-wide `SeriesSearch`. 4. **Update Frontend & Documentation**: Update the client payload, update the OpenAPI spec, and add integration tests covering single/multi/fallback searches. Upon approval, I will execute this plan, merge to `main`, close this ticket referencing the resolving commit, and cut a new point release (v1.7.11).
Gandalf commented 2026-05-24 10:43:07 +01:00
Author
Owner
Copy Link
Copy Source

Resolved in commit 5488969387.

Resolved in commit 54889693878efa9bb801e6e4e11a43ce63080ee2.
Gandalf added the Area/HistoryArea/Matching labels 2026-05-28 11:58:28 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Docker
Docker image and container packaging
 Area/Download Clients
Download client integrations
 Area/Frontend
Client-side UI and build tooling
 Area/History
History and completed downloads views
 Area/Logging
Log streaming, file handling, and debug infrastructure
 Area/Matching
Matching and correlation logic
 Area/Proxy
Upstream service proxy routes
 Area/SSE
Server-Sent Events and real-time streaming
 Area/Webhooks
Webhook processing and reliability
 Compat/Breaking
Breaking change that won't be backward compatible
 Compat/Non-Breaking
Non-breaking compatibility change
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label Area/History Area/Matching Kind/Bug
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Gandalf
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Gandalf/sofarr#44
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?