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

The attention window measures from the grab, not the failure #239

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

§5.7 says a target queues when two failures "happened within the last 30 days".
Every query filters on g.grabbed_at, which is when the torrent was grabbed,
not when it failed. The grabs table (0012_vanished_grabs.sql) has
grabbed_at and imported_at and no failed_at.

A torrent grabbed, left stalling on a slow swarm for five weeks, and then
hard-failing at ffprobe import is stamped with the grab date — already
outside the window the moment the failure is written. Two such failures on a
genuinely broken target never surface in the queue at all, which is the exact
opposite of what §5.7 promises.

The design text and the implementation describe different things. Either the
window measures from the failure and grabs needs the column to measure from,
or §5.7 should say the window runs from the grab and accept what that means.
Decide and make both sides agree.

Note the migration numbers 0024, 0025 and 0027-0029 are reserved by the
subtitles branch; use 0030 upward.

§5.7 says a target queues when two failures "happened within the last 30 days". Every query filters on `g.grabbed_at`, which is when the torrent was *grabbed*, not when it failed. The `grabs` table (`0012_vanished_grabs.sql`) has `grabbed_at` and `imported_at` and no `failed_at`. A torrent grabbed, left stalling on a slow swarm for five weeks, and then hard-failing at `ffprobe` import is stamped with the grab date — already outside the window the moment the failure is written. Two such failures on a genuinely broken target never surface in the queue at all, which is the exact opposite of what §5.7 promises. The design text and the implementation describe different things. Either the window measures from the failure and `grabs` needs the column to measure from, or §5.7 should say the window runs from the grab and accept what that means. Decide and make both sides agree. Note the migration numbers 0024, 0025 and 0027-0029 are reserved by the subtitles branch; use 0030 upward.
naps62-yolo added this to the Feedback pass 2 milestone 2026-08-25 10:30:19 +01:00
naps62-yolo added the area/apidifficulty/hardtype/bug labels 2026-08-25 10:30:19 +01:00
naps62-yolo commented 2026-08-25 11:04:49 +01:00
Author
Owner
Copy Link
Copy Source

Settled as: the window measures from the failure. grabs gains failed_at (migration 0030), the import tick stamps it on hard fail, and every §5.7 window query reads it. §5.7 now states the anchor explicitly.

Adjacent finding, left out of scope: §6.2's pack backoff (pack_backoff_active in tv_grab.rs, pack_allowed in rss.rs, and the season deck in series.rs) also anchors on max(grabbed_at) of failed grabs while calling it last_failed_at. A pack that stalls two weeks and then hard-fails gets its retry backoff computed from the grab, so the quiet period may already be elapsed the moment the failure lands. failed_at now exists to anchor on, but moving §6.2's retry cadence is its own decision, not this issue's.

Settled as: the window measures from the failure. `grabs` gains `failed_at` (migration 0030), the import tick stamps it on hard fail, and every §5.7 window query reads it. §5.7 now states the anchor explicitly. Adjacent finding, left out of scope: §6.2's pack backoff (`pack_backoff_active` in `tv_grab.rs`, `pack_allowed` in `rss.rs`, and the season deck in `series.rs`) also anchors on `max(grabbed_at)` of failed grabs while calling it `last_failed_at`. A pack that stalls two weeks and then hard-fails gets its retry backoff computed from the grab, so the quiet period may already be elapsed the moment the failure lands. `failed_at` now exists to anchor on, but moving §6.2's retry cadence is its own decision, not this issue's.
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/api difficulty/hard 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.
Dependencies

No dependencies set.

Reference: yolo/arr#239
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?