fix: preserve qBittorrent infohash for reused torrents

[wastaken7]

Summary by CodeRabbit

• Bug Fixes
  • Preserved the original torrent’s infohash and origin when a reused torrent is normalized and registered again.
  • Reused torrents now use their original infohash when looking up metadata during preparation.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: cb09cf30-311c-4247-b703-b40d6018749a

📥 Commits

Reviewing files that changed from the base of the PR and between 113ba97 and b288aa9.

📒 Files selected for processing (6)

• src/clients.py
• src/meta.py
• src/prep_helpers.py
• src/torrent_manifest.py
• tests/test_torrent_manifest.py
• tests/test_torrent_reuse.py

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

---

📝 Walkthrough

Walkthrough

Torrent reuse now preserves the candidate client’s infohash in the manifest and uses it during preparation. If no stored reuse infohash is available, preparation continues to read the infohash from the torrent file.

Changes

Torrent reuse infohash

Layer / File(s)	Summary
Store client infohashes src/torrent_manifest.py, src/clients.py, tests/test_torrent_manifest.py	Manifest registration stores the client infohash and retains it when the managed torrent is registered again. The regression test checks that the normalized torrent has a different infohash while retaining the original hash and origin.
Use the stored hash in preparation src/meta.py, src/clients.py, src/prep_helpers.py, tests/test_torrent_reuse.py	Torrent selection copies the stored client infohash to Meta. Preparation uses that value before falling back to the torrent file. The test checks that metadata lookup uses the candidate’s original hash.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: gizeto

Merge Risk: ⚪ Minimal · up to b288a

This change keeps the client's original infohash for reused torrents and uses it for metadata lookup, falling back to the torrent file's hash when none is stored. No merge-blocking risk was identified in the supplied context.

Security Architecture Review

Security architecture risk: 🔵 Low · up to b288a

The change uses a reused torrent’s original hash for metadata lookup without expanding lookup beyond the configured torrent client. No material security regression was established, though recovery and deployment behavior remain uncertain.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed lookup can reach a different torrent record within the selected configured client, but the examined path does not select a new client or grant new client credentials.

Trust Boundaries and Controls

• observed — The original hash comes from a parsed client candidate, not from the normalized managed file. Candidate validation precedes registration, and metadata dispatch requires a configured client; authorization enforced by the remote client is not visible here.

Resilience and Maintainability Implications

• inferred — Manifest loss removes client-hash provenance, while an interrupted two-file update can leave an entry that fails manifest validation. These limits affect recovery of the intended lookup identity; the available comparison does not establish that this PR introduced the persistence window.

Hardening Proposals

• proposed — Consider defining how client provenance should be preserved or recovered when an equivalent external torrent replaces an entry or the manifest is unreadable, so metadata lookup does not depend on incidental registration order.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 21.43% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 14 functions across 6 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: preserving the qBittorrent infohash for reused torrents.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}