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

A root or policy change must re-derive the verdicts it invalidates #241

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

crates/arr-api/src/relocate.rs:4-5 claims a move leaves things so that "the
root's policy (§5.1) applies to a library the files are actually in". Nothing
makes that true.

movies::update (crates/arr-api/src/movies.rs:478) and the series equivalent
(series.rs:630) call reclassify only if overrides_changed. The effective
policy comes from the root, so moving a movie from a main root to a kids
root leaves every stored verdict on its release deck computed under the old
policy until the next sweep — and §9.3's deck and the daemon's manual-grab gate
both read that stored column. That is the failure reclassify.rs's own module
doc exists to prevent.

#236 widens it: PUT /api/roots/{id} writes policy_id
(roots.rs:186-199) with no reclassify at all, so one settings edit can
silently invalidate the verdicts of an entire library.

The root_id half predates this milestone; the doc comment asserting otherwise
is new, and the policy_id half is now a first-class operator action.

Scope: a root change on a title, and a policy change on a root, both re-derive
the verdicts of everything affected. If that is too expensive to do inline for
a whole library, say so in §5.1 and make the sweep the contract instead — but
then the doc comment has to stop claiming it happens.

`crates/arr-api/src/relocate.rs:4-5` claims a move leaves things so that "the root's policy (§5.1) applies to a library the files are actually in". Nothing makes that true. `movies::update` (`crates/arr-api/src/movies.rs:478`) and the series equivalent (`series.rs:630`) call `reclassify` only `if overrides_changed`. The effective policy comes from the root, so moving a movie from a `main` root to a `kids` root leaves every stored verdict on its release deck computed under the old policy until the next sweep — and §9.3's deck and the daemon's manual-grab gate both read that stored column. That is the failure `reclassify.rs`'s own module doc exists to prevent. #236 widens it: `PUT /api/roots/{id}` writes `policy_id` (`roots.rs:186-199`) with no reclassify at all, so one settings edit can silently invalidate the verdicts of an entire library. The `root_id` half predates this milestone; the doc comment asserting otherwise is new, and the `policy_id` half is now a first-class operator action. Scope: a root change on a title, and a policy change on a root, both re-derive the verdicts of everything affected. If that is too expensive to do inline for a whole library, say so in §5.1 and make the sweep the contract instead — but then the doc comment has to stop claiming it happens.
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:15:54 +01:00
Author
Owner
Copy Link
Copy Source

Out of scope here, found while fixing this: PUT /api/policies/{policy_id} (policies.rs update) rewrites a policy's rules with no reclassify at all. That is the third action that invalidates stored verdicts — same failure as the two this issue covers, one level up. reclassify::root now exists, so the fix is small: for each root using the edited policy, re-derive. Needs its own issue.

Out of scope here, found while fixing this: `PUT /api/policies/{policy_id}` (`policies.rs` `update`) rewrites a policy's rules with no reclassify at all. That is the third action that invalidates stored verdicts — same failure as the two this issue covers, one level up. `reclassify::root` now exists, so the fix is small: for each root using the edited policy, re-derive. Needs its own issue.
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/hard type/bug
Milestone
No items
No Milestone Feedback pass 2
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.
Dependencies

No dependencies set.

Reference: yolo/arr#241