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

BUG: rTorrent integration + other secondary gaps (incomplete RPC handling, limited history, fragile error handling) #68

New Issue
Closed
opened 2026-05-28 11:40:32 +01:00 by Gandalf · 1 comment
Gandalf commented 2026-05-28 11:40:32 +01:00
Owner
Copy Link
Copy Source

Description:

Several secondary features have implementation gaps that reduce overall reliability and completeness.

Detailed Investigation Findings (release/1.7.31)

1. rTorrentClient (server/clients/RTorrentClient.js)

  • README explicitly warns that the full RPC endpoint must be provided (e.g., /RPC2).
  • Implementation uses XML-RPC but lacks robust error handling for common rTorrent quirks (authentication, session management, large responses).
  • Likely incomplete normalization and missing features compared to qBittorrent/SABnzbd (similar pattern to Transmission being proof-of-concept).

2. History Depth Limitations

  • SABnzbd history limited to last 10 items.
  • Some retrievers cap maxPages (performance fix), but this can miss older completed downloads.

3. Fragile Error Handling Pattern

  • Many components use "log error + return empty array / null" (graceful degradation).
  • This hides systemic problems (e.g., all download clients failing) and makes debugging harder for users.

4. Other Minor Gaps

  • Debug log streaming has strict subnet restrictions and basic client-side capture.
  • Blocklist search eligibility logic is complex and may not match user expectations.
  • No rate limiting or exponential backoff on some upstream API calls.

Impact:

  • rTorrent users have a sub-par experience.
  • History views can be incomplete.
  • Operational issues are harder to diagnose.

Proposed Solution / Fix Plan:

  1. Review and harden RTorrentClient.js (add better XML-RPC error handling, session management).
  2. Increase configurable history limits with pagination in the UI.
  3. Improve error visibility (e.g., per-instance status in /api/status showing last error).
  4. Add basic rate limiting / backoff where missing.
  5. Update documentation to clearly list limitations for rTorrent and history.

Cross-Dependencies:

  • rTorrent issues affect the same normalized download pipeline as #61 (season packs) and webhook refreshes.
  • Better error visibility would help diagnose issues in all other tickets.

Suggested Labels:
Kind/Bug, Priority: Low–Medium, Area/Download Clients, Area/History, Documentation

Affected Versions: All versions (rTorrent since initial support).

**Description:** Several secondary features have implementation gaps that reduce overall reliability and completeness. ### Detailed Investigation Findings (release/1.7.31) **1. rTorrentClient (`server/clients/RTorrentClient.js`)** - README explicitly warns that the full RPC endpoint must be provided (e.g., `/RPC2`). - Implementation uses XML-RPC but lacks robust error handling for common rTorrent quirks (authentication, session management, large responses). - Likely incomplete normalization and missing features compared to qBittorrent/SABnzbd (similar pattern to Transmission being proof-of-concept). **2. History Depth Limitations** - SABnzbd history limited to last 10 items. - Some retrievers cap `maxPages` (performance fix), but this can miss older completed downloads. **3. Fragile Error Handling Pattern** - Many components use "log error + return empty array / null" (graceful degradation). - This hides systemic problems (e.g., all download clients failing) and makes debugging harder for users. **4. Other Minor Gaps** - Debug log streaming has strict subnet restrictions and basic client-side capture. - Blocklist search eligibility logic is complex and may not match user expectations. - No rate limiting or exponential backoff on some upstream API calls. **Impact:** - rTorrent users have a sub-par experience. - History views can be incomplete. - Operational issues are harder to diagnose. **Proposed Solution / Fix Plan:** 1. Review and harden `RTorrentClient.js` (add better XML-RPC error handling, session management). 2. Increase configurable history limits with pagination in the UI. 3. Improve error visibility (e.g., per-instance status in `/api/status` showing last error). 4. Add basic rate limiting / backoff where missing. 5. Update documentation to clearly list limitations for rTorrent and history. **Cross-Dependencies:** - rTorrent issues affect the same normalized download pipeline as #61 (season packs) and webhook refreshes. - Better error visibility would help diagnose issues in all other tickets. **Suggested Labels:** Kind/Bug, Priority: Low–Medium, Area/Download Clients, Area/History, Documentation **Affected Versions:** All versions (rTorrent since initial support).
Gandalf commented 2026-05-28 16:22:40 +01:00
Author
Owner
Copy Link
Copy Source

Resolved in commit 6fa9c79a7d.

Resolved in commit 6fa9c79a7dd545ae7d35a4abdd4ecaba3ef2a1b2.
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 Area/History Kind/Bug Kind/Documentation
Priority
Medium
3
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#68
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?