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

BUG: qBittorrentClient missing seeds/peers fields in normalized output + unsafe response parsing #64

New Issue
Closed
opened 2026-05-28 11:08:21 +01:00 by Gandalf · 0 comments
Gandalf commented 2026-05-28 11:08:21 +01:00
Owner
Copy Link
Copy Source

Description:

The qBittorrent implementation (server/clients/QBittorrentClient.js) fails to expose important torrent health information (seeds and peers) that is readily available from the Sync API, and contains unsafe response parsing that can cause crashes.

Detailed Investigation Findings (release/1.7.31)

1. Missing Seeds & Peers

  • qBittorrent Sync API returns num_complete (seeds) and num_incomplete (peers/leechers) in torrent objects.
  • normalizeDownload() completely ignores these fields.
  • Normalized output is missing seeds and peers despite being part of the claimed feature set ("seeds, peers, availability").

2. Unsafe Response Parsing

  • Direct property access without checks: 
    const torrents = data.torrents || {};
const rid = data.rid;
  • If the Sync API returns an unexpected shape (network glitch, qBittorrent version difference, or error), this throws and crashes the poller/webhook refresh path.

3. Fallback Logic Issues

  • When falling back to legacy /api/v2/torrents/info, state (lastRid, torrentMap) is reset in a way that can cause repeated full syncs or missed deltas on recovery.

Impact:

  • Dashboard shows incomplete torrent information for the most popular BitTorrent client.
  • Risk of crashes during normal operation under edge conditions.

Proposed Solution / Fix Plan:

  1. Add seeds: torrent.num_complete || 0 and peers: torrent.num_incomplete || 0 to normalizeDownload().
  2. Add defensive checks: 
    if (!data || !data.torrents) { /* handle gracefully */ }
  3. Improve fallback state management (preserve RID where possible).
  4. Add unit tests for malformed responses.

Cross-Dependencies:

  • This affects the same normalized download objects used by season pack handling (#61) and webhook-triggered refreshes. Fixing it improves data quality for all download client views.

Suggested Labels:
Kind/Bug, Priority: Medium, Area/Download Clients, Compat/Non-Breaking

Affected Versions: All versions since qBittorrent support was added.

**Description:** The qBittorrent implementation (`server/clients/QBittorrentClient.js`) fails to expose important torrent health information (seeds and peers) that is readily available from the Sync API, and contains unsafe response parsing that can cause crashes. ### Detailed Investigation Findings (release/1.7.31) **1. Missing Seeds & Peers** - qBittorrent Sync API returns `num_complete` (seeds) and `num_incomplete` (peers/leechers) in torrent objects. - `normalizeDownload()` completely ignores these fields. - Normalized output is missing `seeds` and `peers` despite being part of the claimed feature set ("seeds, peers, availability"). **2. Unsafe Response Parsing** - Direct property access without checks: ```js const torrents = data.torrents || {}; const rid = data.rid; ``` - If the Sync API returns an unexpected shape (network glitch, qBittorrent version difference, or error), this throws and crashes the poller/webhook refresh path. **3. Fallback Logic Issues** - When falling back to legacy `/api/v2/torrents/info`, state (`lastRid`, `torrentMap`) is reset in a way that can cause repeated full syncs or missed deltas on recovery. **Impact:** - Dashboard shows incomplete torrent information for the most popular BitTorrent client. - Risk of crashes during normal operation under edge conditions. **Proposed Solution / Fix Plan:** 1. Add `seeds: torrent.num_complete || 0` and `peers: torrent.num_incomplete || 0` to `normalizeDownload()`. 2. Add defensive checks: ```js if (!data || !data.torrents) { /* handle gracefully */ } ``` 3. Improve fallback state management (preserve RID where possible). 4. Add unit tests for malformed responses. **Cross-Dependencies:** - This affects the same normalized download objects used by season pack handling (#61) and webhook-triggered refreshes. Fixing it improves data quality for all download client views. **Suggested Labels:** Kind/Bug, Priority: Medium, Area/Download Clients, Compat/Non-Breaking **Affected Versions:** All versions since qBittorrent support was added.
Gandalf added the Kind/Bug
Priority
Medium
3
 labels 2026-05-28 11:08:21 +01:00
Gandalf added the Area/Download ClientsCompat/Non-Breaking labels 2026-05-28 11:57: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/Download Clients Compat/Non-Breaking Kind/Bug
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#64
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?