match a download to its job by infohash, not title substring - #35
Merged
JeremiahM37 merged 3 commits intoAug 24, 2026
Merged
Conversation
vedhavyas
marked this pull request as draft
August 24, 2026 03:24
vedhavyas
marked this pull request as ready for review
August 24, 2026 03:33
The downloads endpoint merges a torrent with its job into one entry, but it compared the job title and the torrent name by substring. A repack never matches that way - the job carries the release title and the torrent its own name, and neither contains the other - so the torrent and the job were both emitted and the UI drew two cards for one download: one with a progress bar and no controls, one dismissible with no progress. Use the matcher the watcher already uses, which prefers the infohash and falls back to the title. Its comment says it is shared so the callers cannot disagree; this was a third caller that disagreed.
Matching on the infohash fixes the repack, but the title fallback is still a substring test in both directions, so two torrents in the category whose names both contain a job's title each merged with that same job -- and the endpoint emitted the one job as two cards, which is the duplicate this is meant to remove. The first torrent to match takes the job; a later one is listed as the bare torrent it is, rather than dropped.
The orphan-dedup change landed on main with a caller of the unexported jobMatchesTorrent, which this branch renames.
JeremiahM37
force-pushed
the
fix/downloads-match-by-hash
branch
from
August 24, 2026 07:15
fa015d8 to
dd8cb55
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The downloads endpoint merges a torrent with its job into a single entry, but it matched them by comparing the job title and the torrent name as substrings. A repack never matches that way — the job carries the release title, the torrent carries its own name with the repacker's suffix, and neither contains the other. So the torrent and the job were both emitted, and the UI drew two cards for one download: one with a progress bar and no controls, one dismissible with no progress.
This uses
JobMatchesTorrent, which the watcher already uses and which prefers the infohash. Its own comment says it's shared "so the two cannot disagree" — this was a third caller that disagreed, so exporting it seemed better than a second copy.