fix(scheduler): keep cooldown records for the longest configured cooldown period - #34
Open
linmar wants to merge 1 commit into
Open
fix(scheduler): keep cooldown records for the longest configured cooldown period#34linmar wants to merge 1 commit into
linmar wants to merge 1 commit into
Conversation
…down period The daily prune deleted every search_cooldowns row older than the hard-coded cooldownRetention (7 days), regardless of the configured cooldown_period. Any cooldown longer than a week was therefore silently cut to seven days, and because candidates are taken in library order an instance with a large backlog kept re-searching the same 7 x daily-budget items instead of walking through the backlog. The prune now keeps records for the longest configured cooldown period (global and per instance), with the previous 7 days as the floor. Settings that fail to load are skipped, so an error can only make the prune less aggressive.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The daily prune deletes every
search_cooldownsrow older than the hard-codedcooldownRetention(7 days), regardless of the configuredcooldown_period. Any cooldown longer than a week is therefore silently cut to seven days — and because candidates are taken in library order, an instance with a large backlog keeps re-searching the same7 × daily budgetitems instead of walking through the backlog.Observed on a Whisparr (Eros, registered as
radarr) instance with ~22k monitored-missing items and acooldown_periodof several weeks: after a week the same ~3k items came up again while the rest were never searched.Changes
internal/scheduler: newcooldownPruneRetention()— the prune keeps records for the longest configured cooldown period (global and every instance), with the previous 7 days as the floor. Settings that fail to load are skipped, so an error can only make the prune less aggressive, never more.cooldownRetentionupdated to describe it as the floor.TestCooldownPruneRetentionHonoursConfiguredPeriods(defaults → 7 d floor; longer global; longest per-instance wins).Related issues
none
Test plan
make test)make lint— 0 issues)