Description
_process_death_row calls _filter_by_duration (app/deleterr.py) BEFORE reading is_dry_run, and _filter_by_duration writes tagged dates into the state file via set_tagged_dates for any death-row item that lacks a state entry.
So a dry_run: true run - the mode users are told to trust while evaluating the tool - alters .deleterr_state.json and with it the real deletion timing: leaving-soon duration timers start (or restart) from the dry run, not from when items were actually tagged in a real run.
Failure Scenario
User runs a few dry runs over several days while tuning config, then flips dry_run: false. Items appear to have been "in leaving soon" since the dry runs, so their duration elapses earlier than the user expects from their first real run.
Proposed Fix
- Pass
is_dry_run into _filter_by_duration and skip all set_tagged_dates writes in dry-run mode (log what WOULD be recorded instead)
- Audit for any other state writes reachable in dry-run
- Test: a dry run leaves the state file byte-identical
Description
_process_death_rowcalls_filter_by_duration(app/deleterr.py) BEFORE readingis_dry_run, and_filter_by_durationwrites tagged dates into the state file viaset_tagged_datesfor any death-row item that lacks a state entry.So a
dry_run: truerun - the mode users are told to trust while evaluating the tool - alters.deleterr_state.jsonand with it the real deletion timing: leaving-soon duration timers start (or restart) from the dry run, not from when items were actually tagged in a real run.Failure Scenario
User runs a few dry runs over several days while tuning config, then flips
dry_run: false. Items appear to have been "in leaving soon" since the dry runs, so their duration elapses earlier than the user expects from their first real run.Proposed Fix
is_dry_runinto_filter_by_durationand skip allset_tagged_dateswrites in dry-run mode (log what WOULD be recorded instead)