Skip to content

fix: accept qBittorrent 5.2 torrent-add responses - #420

Merged
kikootwo merged 4 commits into
mainfrom
reland/295-qbit-add-response
Oct 20, 2026
Merged

kikootwo merged 4 commits into
mainfrom
reland/295-qbit-add-response

Conversation

@kikootwo

@kikootwo kikootwo commented Oct 20, 2026 •

Copy link
Copy Markdown
Owner

Linked issue

Re-lands #295 by @ColeTown, who wrote the original fix and is credited as co-author on these commits. #295 gets closed once this merges. Reported in #317.

What changed

qBittorrent 5.2 (WebAPI 2.14 and later) answers /api/v2/torrents/add with a JSON receipt instead of the plain Ok. text (upstream change), so RMAB reported a failed grab even when qBittorrent had accepted the torrent.

  • Both the magnet and .torrent upload paths now accept either Ok. or a receipt that confirms exactly the hash RMAB submitted: one success, no failures, nothing pending. Anything else is still an error, and the existing duplicate handling is unchanged.
  • A rejected receipt is logged with its content (capped at 500 characters) instead of [object Object], so a hash mismatch shows the ID qBittorrent returned.
  • Known limit, documented in documentation/phase3/qbittorrent.md: for hybrid (v1+v2) torrents on libtorrent-2 builds, and for base32 magnets, qBittorrent's receipt carries a different hash than the one RMAB computes, so those adds are still reported as failed. Tracking those torrents didn't work before 5.2 either. That's a separate follow-up.

Checks

  • 44 tests over local HTTP with real axios and torrent parsing, on both upload paths: legacy and JSON success, malformed or mismatched receipts, pending additions, HTTP errors and existing downloads. The JSON-success cases fail on main.
  • Tested together with fix: wait for SABnzbd post-processing before completing a download #421 (the SABnzbd re-land) on main: the full unit suite in the Node 24 test container passes (297 files, 3,998 passed, 5 skipped), and so do the image build, the smoke test and an end-to-end import spec (3/3).
  • Sign-in on 5.2 is unaffected: it checks the session cookie, not the response body.

Risk and rollback

  • Only the add-response check changes. qBittorrent 4.x, 5.0 and 5.1 still answer Ok., which is accepted as before.
  • Rollback: revert this PR.

Release note

Torrents added to qBittorrent 5.2 or later are no longer reported as failed grabs.

🤖 Generated with Claude Code

kikootwo and others added 4 commits October 20, 2026 14:48
qBittorrent 5.2 answers /api/v2/torrents/add with a JSON receipt instead
of the plain "Ok." text, so ReadMeABook reported a failed grab even when
the client had accepted the torrent.

Both the magnet and .torrent upload paths now accept either the legacy
text or a receipt that confirms exactly the hash we submitted: one
success, no failures, nothing pending. Anything else is still an error.

Re-lands #295 by @ColeTown.

Co-authored-by: Cole Townsend <33290898+ColeTown@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A rejected JSON receipt was interpolated as "[object Object]", so the
log never showed which ID qBittorrent returned. Rejection messages now
keep text bodies as they are and serialize JSON (capped at 500 chars).

The 202 and 409 tests now also assert that the upload happened, and
qbittorrent.md records the known hybrid/base32 hash limit as a
follow-up.

Co-authored-by: Cole Townsend <33290898+ColeTown@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant