yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

A pack abandoned at import is invisible in the UI #227

New Issue
Closed
opened 2026-08-25 08:09:55 +01:00 by naps62-yolo · 1 comment
naps62-yolo commented 2026-08-25 08:09:55 +01:00
Owner
Copy Link
Copy Source

When a pack hard-fails at import, the download stays complete in Transmission
and nothing in the UI says the grab was abandoned.

The sequence, from production on Rick and Morty S08:

  1. arr grabbed a season pack and Transmission downloaded it in full
  2. import evaluated each file, one fell below the per-episode size floor, and
    §5.7 condemned the whole release
  3. hard_fail_tv blacklisted it, set the grab to failed, and wrote all ten
    episodes back to missing
  4. §7.3 leaves the torrent alone deliberately — the reaper owns that lifecycle

The result the operator sees is a torrent sitting at 100% in Transmission and a
season reading 0/10 in arr, with nothing connecting the two. They found out by
opening Transmission and asking why.

Every fact needed is already recorded. grabs holds the failed row, the
blacklist holds the release name and the reason string hard_fail_tv was
called with — "no file matches a wanted episode", or the name of the rule that
rejected it. None of it reaches the UI.

Surface it where the operator already looks:

  • the season detail row, or its release deck, should be able to say a grab for
    this season failed at import and why, rather than leaving the season looking
    as though nothing was ever tried
  • a blacklisted row in the deck already renders as blacklisted; it should be
    able to show the reason it was blacklisted for, since that is the difference
    between "this release is bad" and "your policy rejected it"

The second one matters most: a size rejection means the operator can waive it
(#210) and try again, while a corrupt release means they should not. Those look
identical today.

Depends on: #211

Non-goals: do not make arr delete or reclaim the orphaned torrent — §7.3 is
deliberate and the reaper owns it. Do not import a torrent arr did not grab;
§2 rules out filesystem scanning permanently. This issue is about telling the
operator what already happened, not changing what happens.

When a pack hard-fails at import, the download stays complete in Transmission and nothing in the UI says the grab was abandoned. The sequence, from production on Rick and Morty S08: 1. arr grabbed a season pack and Transmission downloaded it in full 2. import evaluated each file, one fell below the per-episode size floor, and §5.7 condemned the whole release 3. `hard_fail_tv` blacklisted it, set the grab to `failed`, and wrote all ten episodes back to `missing` 4. §7.3 leaves the torrent alone deliberately — the reaper owns that lifecycle The result the operator sees is a torrent sitting at 100% in Transmission and a season reading 0/10 in arr, with nothing connecting the two. They found out by opening Transmission and asking why. Every fact needed is already recorded. `grabs` holds the failed row, the blacklist holds the release name and the **reason string** `hard_fail_tv` was called with — `"no file matches a wanted episode"`, or the name of the rule that rejected it. None of it reaches the UI. Surface it where the operator already looks: - the season detail row, or its release deck, should be able to say a grab for this season failed at import and why, rather than leaving the season looking as though nothing was ever tried - a blacklisted row in the deck already renders as `blacklisted`; it should be able to show the reason it was blacklisted for, since that is the difference between "this release is bad" and "your policy rejected it" The second one matters most: a size rejection means the operator can waive it (#210) and try again, while a corrupt release means they should not. Those look identical today. Depends on: #211 Non-goals: do not make arr delete or reclaim the orphaned torrent — §7.3 is deliberate and the reaper owns it. Do not import a torrent arr did not grab; §2 rules out filesystem scanning permanently. This issue is about telling the operator what already happened, not changing what happens.
naps62-yolo added the area/webdifficulty/moderatetype/bug labels 2026-08-25 08:09:55 +01:00
naps62-yolo added a new dependency 2026-08-25 08:09:55 +01:00
#226 The attention queue flags a season on one failed grab
naps62-yolo added this to the Feedback pass 2 milestone 2026-08-25 08:17:44 +01:00
naps62-yolo commented 2026-08-25 12:11:56 +01:00
Author
Owner
Copy Link
Copy Source

Out-of-scope finding while working this issue, filed here rather than fixed silently.

web/scripts/check-tokens.mjs strips /* */ and // comments before scanning for literal colours, but not HTML comments. An issue reference of three or more digits inside an index.html comment — <!-- #227: ... --> — reads as a hex colour and fails just ci. Existing comments only reference two-digit issues, so nothing had tripped it before. Worked around by writing issue 227 instead; the checker should strip <!-- --> the way it strips the other two.

Out-of-scope finding while working this issue, filed here rather than fixed silently. `web/scripts/check-tokens.mjs` strips `/* */` and `//` comments before scanning for literal colours, but not HTML comments. An issue reference of three or more digits inside an `index.html` comment — `<!-- #227: ... -->` — reads as a hex colour and fails `just ci`. Existing comments only reference two-digit issues, so nothing had tripped it before. Worked around by writing `issue 227` instead; the checker should strip `<!-- -->` the way it strips the other two.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/web difficulty/moderate type/bug
Milestone
No items
No Milestone Feedback pass 2
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Depends on
#226 The attention queue flags a season on one failed grab
yolo/arr
Reference: yolo/arr#227
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?