Throttle repeated *arr history-error logs (fixes #21)#29
Conversation
When a Sonarr/Radarr is misconfigured or unreachable, the history check fails for every transfer on every poll, and each failure logged an error. Over weeks this grew the log to many GB and filled users' disks. Throttle the error to at most once per 5 minutes per *arr, so the problem stays visible without runaway log growth.
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR adds throttled logging for connection/history retrieval errors from Sonarr/Radarr to prevent repeated poll failures from spamming logs and filling disk (issue #21).
Changes:
- Track last logged connection error per *arr in
StateManager. - Add a configurable throttling interval (
ARR_ERROR_LOG_INTERVAL) and a helper method to decide whether to log. - Update transfer polling to suppress repeated error logs within the throttling window.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/state.rs | Adds per-*arr error log throttling state and should_log_arr_error helper. |
| src/download_system/transfer.rs | Uses throttling helper to suppress repeated “retrieving history” errors. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Key the *arr error throttle on the app's existing name field instead of app.to_string(), so the suppressed (common) path does no allocation. The full Display form is still used in the log message itself.
Instant::duration_since can panic if the stored instant is somehow later than now; saturating_duration_since returns zero instead, making the throttle robust regardless.
The log message hardcoded '5m' while the interval is defined by ARR_ERROR_LOG_INTERVAL; format the constant into the message so the two can't drift if the interval is changed.
|
@bugrax after merging the other 2 PRs this one has a conflict.. mind having a look? |
…logs # Conflicts: # src/state.rs
|
Done — just merged |
Fixes #21.
When a Sonarr/Radarr instance is misconfigured or unreachable,
is_importedfails its history lookup for every transfer on every poll, and each failure logged:With a 10s poll and any number of transfers that is a continuous stream of identical lines. The reporter saw it grow to ~23 GB and fill a 50 GB disk over a couple of months.
This throttles that specific error to at most once per 5 minutes per *arr (tracked in
StateManager). The problem is still visible in the logs, but it can no longer grow without bound. Functional behaviour is unchanged — only the logging is rate-limited.(A docker
logging: max-sizeis a good defence-in-depth too, but this stops the root cause of the growth.)