Notification trigger on provider degradation — breaker re-opening, or zero downloads while searches succeed

[Svnow132]

Summary

Bridge the existing circuit breakers and the existing notification channels: push one alert when a provider is repeatedly tripping its breaker, or when downloads flatline while searches keep succeeding.

What problem does this feature solve?

Sublarr already has circuit breakers and notification channels, but no bridge between them: a provider can fail permanently (expired auth, dead key, gate misconfiguration) and the only symptom is a quietly stagnant wanted queue. On our install, the primary provider was dead for 3 days before anyone noticed (#NN Bug 1) — the failure signature ("searches fine, downloads zero") was sitting in the stats the whole time, but nothing pushed it.

What do you propose?

New notification triggers, off by default, routed through the existing channels/templates:

• circuit breaker for a provider opened ≥ N times within 24 h
• zero successful downloads in X h while ≥ Y searches succeeded (the "searches fine, downloads dead" signature)
• a provider auto-disabled, or all its pool keys exhausted/429-cooling

Rate-limited to one alert per condition per provider per day — the point is the first ping, not a stream. Pairs naturally with the health panel (FR: provider health status): the panel shows it, the hook pushes it.

Alternatives considered

• External log-scraper alerting (Loki/grep cron) — needs extra infra and breaks whenever a log message changes wording; several relevant events only log at DEBUG.
• Polling provider_stats via API — possible, but auth/gate state isn't exposed, and every user would be rebuilding the same watchdog Sublarr already has the data for.
• FR 2 panel alone — visibility without push still requires someone to look; the 3-day outage in #NN happened precisely because nobody had a reason to look.

[Abrechen2]

Implemented in v1.11.0, off by default.

Two conditions: a provider that was auto-disabled, and one that is still searching while nothing downloads. At most one alert per provider per condition per day — the point is the first ping, not a stream.

Most of the work went into not crying wolf. On a healthy install most providers legitimately never download, because they lose the scoring race, so alerting on "no downloads" alone would bury the one provider that genuinely broke under a dozen that are fine. It therefore fires only for a provider demonstrably still in use: searching within the last 6 hours, and with downloads in its history. Each of those exclusions has its own test, because each is a false positive that would otherwise have shipped.

Detection runs and logs regardless of the setting, so the finding is in the log even with notifications switched off.