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

BUG: TransmissionClient is incomplete / proof-of-concept only (missing arrQueueId, control methods, status mapping) #63

New Issue
Closed
opened 2026-05-28 10:40:44 +01:00 by Gandalf · 0 comments
Gandalf commented 2026-05-28 10:40:44 +01:00
Owner
Copy Link
Copy Source

Description:

The Transmission download client implementation (server/clients/TransmissionClient.js) is only a partial / proof-of-concept integration despite being listed as a fully supported download client in the README and architecture docs.

Detailed Investigation Findings (release/1.7.31)

1. Incomplete extractArrInfo()

  • Detects series (SxxEyy) and movie (year in parentheses) patterns but never extracts queueId.
  • Returns only { type: 'series' | 'movie' } → arrQueueId and arrType are always undefined in the normalized output.
  • Breaks user-specific matching and history linking for Transmission users.

2. Incomplete Status Mapping

  • Transmission status codes 1 (Queued), 2 (Checking), 3 (Queued) are handled, but 7 (TORRENT_IS_CHECKING) is incorrectly mapped to "Unknown" (it should be "Checking").
  • Missing proper handling for other edge states.

3. Missing Control Methods

  • The DownloadClient base class interface expects startTorrent(), stopTorrent(), removeTorrent(), etc. (part of the Pluggable Download Client Architecture – PDCA).
  • TransmissionClient implements none of them.

4. Other Robustness Issues

  • No timeout or retry logic in makeRequest().
  • No validation for missing arguments.torrents in responses → potential runtime errors on unexpected API replies.
  • Session ID handling for 409 errors is present but fragile.

Impact:

  • Transmission users get incomplete or broken download information.
  • No ability to control torrents from the dashboard.
  • Contradicts the "full support for Transmission" claim.

Proposed Solution / Fix Plan:

  1. Complete extractArrInfo() to also return queueId (parse from filename or use Transmission's id field mapped to Sonarr/Radarr queue).
  2. Fix status mapping (add TORRENT_IS_CHECKING → "Checking").
  3. Implement the missing control methods using Transmission RPC (torrent-start, torrent-stop, torrent-remove).
  4. Add defensive response validation and timeout/retry logic.
  5. Update README to mark Transmission as "experimental / partial support" until complete, or fully implement it.

Cross-Dependencies:

  • This affects the same normalized download pipeline used by the season pack queue handling (#61) and webhook refreshes.
  • Once fixed, Transmission downloads will correctly appear in the dashboard alongside Sonarr/Radarr data.

Suggested Labels:
Kind/Bug, Priority: High, Area/Download Clients, Compat/Non-Breaking (with note that control methods are new)

Affected Versions: All versions since Transmission support was added.

**Description:** The Transmission download client implementation (`server/clients/TransmissionClient.js`) is only a partial / proof-of-concept integration despite being listed as a fully supported download client in the README and architecture docs. ### Detailed Investigation Findings (release/1.7.31) **1. Incomplete `extractArrInfo()`** - Detects series (`SxxEyy`) and movie (year in parentheses) patterns but **never extracts `queueId`**. - Returns only `{ type: 'series' | 'movie' }` → `arrQueueId` and `arrType` are always undefined in the normalized output. - Breaks user-specific matching and history linking for Transmission users. **2. Incomplete Status Mapping** - Transmission status codes `1` (Queued), `2` (Checking), `3` (Queued) are handled, but `7` (`TORRENT_IS_CHECKING`) is incorrectly mapped to `"Unknown"` (it should be "Checking"). - Missing proper handling for other edge states. **3. Missing Control Methods** - The `DownloadClient` base class interface expects `startTorrent()`, `stopTorrent()`, `removeTorrent()`, etc. (part of the Pluggable Download Client Architecture – PDCA). - TransmissionClient implements none of them. **4. Other Robustness Issues** - No timeout or retry logic in `makeRequest()`. - No validation for missing `arguments.torrents` in responses → potential runtime errors on unexpected API replies. - Session ID handling for 409 errors is present but fragile. **Impact:** - Transmission users get incomplete or broken download information. - No ability to control torrents from the dashboard. - Contradicts the "full support for Transmission" claim. **Proposed Solution / Fix Plan:** 1. Complete `extractArrInfo()` to also return `queueId` (parse from filename or use Transmission's `id` field mapped to Sonarr/Radarr queue). 2. Fix status mapping (add `TORRENT_IS_CHECKING` → "Checking"). 3. Implement the missing control methods using Transmission RPC (`torrent-start`, `torrent-stop`, `torrent-remove`). 4. Add defensive response validation and timeout/retry logic. 5. Update README to mark Transmission as "experimental / partial support" until complete, or fully implement it. **Cross-Dependencies:** - This affects the same normalized download pipeline used by the season pack queue handling (#61) and webhook refreshes. - Once fixed, Transmission downloads will correctly appear in the dashboard alongside Sonarr/Radarr data. **Suggested Labels:** Kind/Bug, Priority: High, Area/Download Clients, Compat/Non-Breaking (with note that control methods are new) **Affected Versions:** All versions since Transmission support was added.
Gandalf added the Kind/Bug
Priority
Low
4
 labels 2026-05-28 10:40:44 +01:00
Gandalf added the Area/Download ClientsCompat/Non-Breaking labels 2026-05-28 11:57:25 +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/Download Clients Compat/Non-Breaking Kind/Bug
Priority
Low
4
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#63
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?