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

Turning a season's tracking off clears its episodes' wanted #171

New Issue
Closed
opened 2026-08-24 16:12:28 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-24 16:12:28 +01:00
Owner
Copy Link
Copy Source

Implements the §4.1 reversal from #169: turning a season's tracking off clears
wanted on every episode of that season.

Depends on: #169

PATCH /api/series/{series_id}/seasons/{number} with {"tracked": false} must
clear wanted on that season's episodes, in the same transaction as the flag
write. The tracked: true direction keeps its current behaviour unchanged.

The clear must be idempotent, and must run even when the season is already
untracked. This is the part that matters and the easy part to miss. Production
already holds seasons whose tracked is false while their episodes are all still
wanted — that is the state the old ruling made reachable and gave no way out of.
If the handler short-circuits on "the flag already has this value, nothing to do",
those rows stay stranded forever and the issue is not fixed. Sending
{"tracked": false} to an already-untracked season is the operator's way to clear
it, so it has to do the work.

Season 0 is included. It is skipped by the auto-track rules, but an operator
untracking it means the same thing there as anywhere else.

Deliberately not doing: a migration that clears wanted on every untracked season.
§4.1 explicitly supports marking individual episodes wanted on a season that was
never tracked, and a blanket sweep would destroy exactly that intent. Existing
rows are cleared by the operator acting on them, one season at a time.

Where the logic goes: the decision belongs in arr-core next to the other §4.1
rules in tracking.rs if it can be expressed without IO, with arr-api supplying
the rows and persisting the result. arr-core must not gain a sqlx dependency.

Tests: an already-untracked season with wanted episodes gets them cleared; a
tracked season being turned off gets them cleared; turning tracking on is
unaffected; a season with no episodes is a no-op rather than an error. Regenerate
and commit .sqlx/ if the queries change.

Implements the §4.1 reversal from #169: turning a season's tracking off clears `wanted` on every episode of that season. Depends on: #169 `PATCH /api/series/{series_id}/seasons/{number}` with `{"tracked": false}` must clear `wanted` on that season's episodes, in the same transaction as the flag write. The `tracked: true` direction keeps its current behaviour unchanged. **The clear must be idempotent, and must run even when the season is already untracked.** This is the part that matters and the easy part to miss. Production already holds seasons whose `tracked` is false while their episodes are all still wanted — that is the state the old ruling made reachable and gave no way out of. If the handler short-circuits on "the flag already has this value, nothing to do", those rows stay stranded forever and the issue is not fixed. Sending `{"tracked": false}` to an already-untracked season is the operator's way to clear it, so it has to do the work. Season 0 is included. It is skipped by the auto-track rules, but an operator untracking it means the same thing there as anywhere else. Deliberately not doing: a migration that clears wanted on every untracked season. §4.1 explicitly supports marking individual episodes wanted on a season that was never tracked, and a blanket sweep would destroy exactly that intent. Existing rows are cleared by the operator acting on them, one season at a time. Where the logic goes: the decision belongs in `arr-core` next to the other §4.1 rules in `tracking.rs` if it can be expressed without IO, with `arr-api` supplying the rows and persisting the result. `arr-core` must not gain a sqlx dependency. Tests: an already-untracked season with wanted episodes gets them cleared; a tracked season being turned off gets them cleared; turning tracking on is unaffected; a season with no episodes is a no-op rather than an error. Regenerate and commit `.sqlx/` if the queries change.
naps62-yolo added this to the Removal and navigation milestone 2026-08-24 16:12:28 +01:00
naps62-yolo added the area/apiphase/6-tvdifficulty/moderatetype/feature labels 2026-08-24 16:12:28 +01:00
naps62-yolo added a new dependency 2026-08-24 16:13:22 +01:00
#174 Delete files and untrack, for one season or one episode
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 labels area/api difficulty/moderate phase/6-tv type/feature
Milestone
No items
No Milestone Removal and navigation
Projects
Clear projects
No projects
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.
Blocks
#174 Delete files and untrack, for one season or one episode
yolo/arr
Depends on
#169 Amend DESIGN.md: untracking clears intent, library is the homepage
yolo/arr
Reference: yolo/arr#171