[ccarpinteri]

Closes #2046.

What it does

Adds a per client "remove on import" toggle, off by default. When it is on, Bindery removes the torrent from the client once it has imported the download. deleteFiles is false, so the files stay on disk and a hardlinked import keeps working.

Off by default for the reason you raised on the issue: private tracker users need it off, because removing a torrent stops it seeding and costs them ratio. The help text under the toggle says so.

Wiring it into every success route

You said the import path has more than one success route and the callback needs to be at each of them, so I went through them all.

tryImportInternal already ran cleanupFunc on three routes. The fourth, the "no book files at the path but the book is already in the library" return, did not, so it does now.

The two "book already in library" shortcuts in checkQbittorrentDownloads were the real gap. Both close a download out and mark it imported without ever calling tryImportInternal, so no cleanup could have run there at all. They now build the same callback through a shared helper, qbittorrentRemoveOnImportCleanup.

Transmission's poller has no equivalent shortcut. Everything goes through tryImportInternal, so it was already covered.

The manual import API path builds a synthetic Download with no TorrentID and no client, so there is nothing to remove and it is left alone.

Usenet

Untouched. tryImportNZBGet already calls RemoveHistory on import unconditionally, so there is nothing for the toggle to control. The settings form hides it for usenet clients, and the edit form sends it as false if a client is switched from a torrent type to a usenet one, so a stale flag cannot be left on the row.

UI

Checkbox in Settings, Download Clients, under the path remap field, for torrent clients only. Screenshot of it on my own install with Transmission selected: the toggle, the label "Remove torrent after import", and the help text explaining the ratio tradeoff.

Tests

• ClientsTab.test.tsx: hidden for usenet, reflects the stored value, defaults off and sends the change on save, never sent enabled for a usenet client
• existing SettingsPage payload assertions updated, since torrent clients now carry the extra key
• Go side: importer and db suites pass, including the existing cleanup callback tests

Full web suite: 92 files, 1058 tests, passing. It needs Node 21 or newer to run, since jsdom's undici calls webidl.util.markAsUncloneable; on Node 20 the suite cannot start. I ran it on the same Node the Dockerfile uses.

Note on ordering

Stacks on #2711 and #2712. #2711 matters for this one: it makes a Transmission download's stored identifier stable. Without it, a stored id can come back pointing at a different torrent after a daemon restart, and this feature would then remove a torrent the user never grabbed. I would rather this did not land first.

Migration is numbered 090 against current main.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 57.81250% with 27 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/importer/scanner_poll.go	47.36%	17 Missing and 3 partials ⚠️
internal/db/download_clients.go	78.26%	3 Missing and 2 partials ⚠️
internal/importer/scanner.go	33.33%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[Ararana]

Thanks for this, it covers exactly the gap I hit. One request: could the toggle offer a "remove torrent and data" option alongside "remove torrent only"?

[vavallee]

Heads up on a migration number collision, not a review.

This PR adds a migration numbered 090, and so do two others that are open right now: #2761 and #2713 and #2750 all claim 090. assertUniqueMigrationVersions (internal/db/db.go:685) refuses to boot when two files share a numeric prefix, so whichever of the three merges second breaks startup for anyone who has both.

Main tops out at 089. Current claim map across the open PRs:

• 086 → feat(author): drop thin edition clusters from catalogue sync (#2235) #2673, Feature/download client media eligibility #2633 (also a collision, and 086 is a gap on main that three different branches have each filled with something different)
• 090 → feat(api): auto-approve requests per requester account (#2718) #2761, feat(indexer): normalise the audiobook size bonus by runtime and cap grabs (#2740) #2750, feat(downloader): remove the torrent after a successful import (#2046) #2713
• 091 → fix(scheduler): stop a failed queue row blocking an automatic re-grab (#2710) #2714
• 092 → feat(quality): rank releases by profile order, best first (#2733) #2737
• 093 is the first genuinely free number

The usual gotcha here is that each of us computes "next free" against a main that does not yet contain anyone else's unpushed work, so this keeps happening. Worth renaming to something above 093 and picking by checking open PRs rather than main. No rush on my side, just flagging it before two of these land in the same window.

[vavallee]

Off by default, per client, `deleteFiles` false so a hardlinked import survives, and you found the two qBittorrent "already in library" shortcuts that never reached `tryImportInternal`. That last one is the kind of thing that only turns up by actually walking every success route, so thanks for doing it. Refusing to land before #2711 is the right call too: without stable ids this would remove somebody else's torrent.

090 is fine: main has nothing there, and the other PR claiming it (#2750) has been asked to move to 095.

Two small things before merge: `misspell` fails on "hardlinked" in a comment at `scanner_poll.go:1023` (writing "hard linked" clears it), and the same DCO sign-off as the other two. Passes merged onto main otherwise.

[vavallee]

Pushed a one word comment fix so the lint job passes: misspell was flagging "hardlinked" in scanner_poll.go, now "hard linked". That was the only one the PR added. Thanks ccarpinteri!