[ccarpinteri]

Problem

torrent-add returns a numeric id that is scoped to the daemon session. Transmission renumbers every torrent when it restarts. Bindery stores that id as the download's TorrentID and the poller looks downloads up by it, so every restart breaks the link.

After a restart the stored id matches nothing. checkTransmissionDownloads skips the row, the download sits at "downloading" for good, and the torrent keeps seeding. Nothing ever imports it.

Ids are also reused. A stored id can come back pointing at a different torrent, and then Bindery acts on the wrong one: the wrong payload is imported, and anything that removes by id removes a torrent the user never grabbed.

I hit this on my own install. Two downloads had been stranded for weeks:

download	stored id	actual id after restarts
audiobook grabbed 4 Sep	5	2
ebook grabbed 16 Aug	17	1

Both torrents were healthy and sitting in the client the whole time. One of them was complete and ready to import.

qBittorrent does not have this problem because it stores the hash. Transmission is the only torrent client keyed on a value that changes.

Change

Store hashString, which stays the same for the life of the torrent, and look downloads up by it. The RPC accepts a hash anywhere it accepts an id, so removal works off the same value with no extra lookup.

Two other places compared the stored value against a map keyed by numeric id, and both are keyed by hash now:

• GetStalledIDs, with no numeric fallback. The caller removes what this matches, so a stale id here would remove the wrong torrent.
• GetLiveStatuses, which keeps the numeric id as an extra key. That overlay only draws a queue row, so the worst a stale id can do is mislabel one.

Rows written before this change

Those still hold a numeric id. They are matched by comparing Transmission's addedDate against the download's grab time, which a restart does not change, and only when the pairing is clear:

• no download near a torrent's added time: leave the torrent alone
• exactly one: assign it
• several, which happens with a batch of grabs minutes apart: the release name has to pick out exactly one, otherwise leave it for the user

The row is then rewritten to the hash. This is the same recovery shape as the qBittorrent hash backfill in #939.

The stale id is never used to find the torrent. Leaving a download stuck can be undone; removing the wrong torrent cannot. Terminal downloads are skipped for the same reason: they will not be imported or removed again, so rewriting their identifier can only be wrong.

I got this wrong on the first pass in a way worth mentioning. An earlier version accepted any single torrent inside the time window without the name check, and on a live database seven already imported rows from one afternoon's grabs all matched the one torrent from that window that still existed. The mutual uniqueness rule and the terminal skip are there because of it, and TestCheckTransmissionDownloads_LegacyBatchDoesNotCollapseOntoOneTorrent covers exactly that case.

Tests

New in internal/importer/scanner_transmission_hash_test.go:

• a download stranded by a renumbered id is recovered and rewritten to the hash
• a stale id that now belongs to an unrelated torrent is ignored, and the row is left alone
• a batch of downloads grabbed in one window does not collapse onto a single torrent
• the release name comparison, which has to tolerate +, _ and . where a tracker put them instead of spaces

Existing fixtures that asserted id based identity now assert hash based identity. AddTorrent keeps its signature and delegates to a new AddTorrentDetailed that returns the whole torrent, so nothing else that calls it had to change.

Full importer, downloader, db, scheduler and api suites pass. The two failures I see locally, TestFindCaseInsensitivePathUnder and TestDiagnose_CaseDivergenceWarns, also fail on a clean checkout of main on macOS.

Running on my own install since this morning, with both stranded downloads recovered on the first poll.

Note on ordering

This is the first of three. The other two stack on it: polling the audiobook category, and the remove on import feature from #2046. That one needs this fix to be safe, since it removes the torrent it matched.

Maintainer follow ups

Pushed on top of the original commit, which is unchanged:

• The legacy reconciler now requires a match to be unique from the download's side too. Before, one legacy row with its own torrent and an unrelated torrent in the same five minute window (a shared daemon, or no category filter) got whichever torrent the daemon listed first. TestCheckTransmissionDownloads_LegacyRowWithTwoNearbyTorrentsIsLeftAlone failed on the previous head with the row rewritten to the unrelated hash.
• RemoveTransmissionTorrent no longer removes by a stored numeric id. Those rows are exactly the ones the poller could not pair, so the number may name someone else's torrent. It now returns an error without calling the daemon; queue removal still drops the row and stall handling still blocklists and re-searches.
• A test pinning the terminal row skip, which no test caught when disabled.
• The changelog.d fragment.

Closes #2808

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 86.18421% with 21 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/importer/scanner_poll.go	91.66%	5 Missing and 4 partials ⚠️
internal/downloader/transmission/client.go	69.56%	7 Missing ⚠️
internal/downloader/adapter.go	76.19%	2 Missing and 3 partials ⚠️

📢 Thoughts on this report? Let us know!

[vavallee]

This is a really good fix, and thanks for writing up the first pass that went wrong. The batch collapsing onto one torrent is exactly the trap I'd have wanted a test for, and you have one.

I checked the premise on main: `checkTransmissionDownloads` keys its lookup on `fmt.Sprintf("%d", t.ID)`, the session id, so a restart strands every row just as you describe. Merged onto current main with #2712 and #2713 stacked on top, all three build, vet, and `importer`, `downloader`, `db`, `scheduler` and `api` pass. I also added a numeric id fallback to the lookup as a mutation, which is the one thing this must never do, and `TestCheckTransmissionDownloads_IgnoresRecycledTorrentID` caught it.

Only blocker is the DCO check: the commits have no `Signed-off-by` at all. From each branch, `git rebase --exec 'git commit --amend --no-edit -s' origin/main` then force push. Since they stack, doing it on #2713's branch and pushing each branch from there is simplest.

[vavallee]

Merged, thanks! I pushed a few commits on top before merging: the recovery pairing for old numeric rows now has to be unambiguous from both sides (an unrelated torrent added in the same window could get picked), and removal refuses a stale numeric id instead of deleting whatever holds that number now. Also added the changelog fragment. For next time, please sign off your commits with git commit -s so the DCO check passes.