Reclassify can leave half a library stale with no way back #247
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: yolo/arr#247
Reference in New Issue
Block a user
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?
All four callers of
reclassify—policies.rs:442,roots.rs:251,movies.rs:488,series.rs:634— run after the write has alreadycommitted, and
reclassify::applyissues one autocommittedUPDATEperchanged row with no enclosing transaction. The walk is also N+1: one
policy lookup plus one releases fetch per title.
Failure scenario, at the size §5.1 now cites (2000 titles, 10 000 releases):
a policy edit gets halfway, then one row's
parsedblob fails to deserialise(
reclassify.rs:210) or SQLite hits the busy timeout. The handler returns 500.The policy row is already changed, roughly half the verdicts are re-derived
and half are not, and nothing else in the system re-reads that column, so the
stale half stays stale permanently.
§5.1's new paragraph says "The operator is never left reading a verdict computed
under a policy that no longer applies". A 500 here leaves exactly that, and the
only signal is an error on a request whose primary effect succeeded.
Scope: make the re-derivation and the write that triggered it succeed or fail
together, or give the stale half a way to be noticed and repaired. Batching the
updates and dropping the N+1 is worth doing in the same pass, but the recovery
path is the point.
Not urgent for correctness in the common case — #246 measured 0.36s to 2.7s over
that data set — but the failure mode is silent and permanent, which is the
combination §5.1 was written to rule out.