alex/manage
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add typed qBittorrent scheduled polling

Browse Source
This commit is contained in:
Developer
2026-07-14 15:22:34 +00:00
parent eac9b5d33d
commit a9488af0b4
22 changed files with 2036 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/REQUIREMENTS.md
+15
View File
@@ -296,6 +296,21 @@ Multiple instances per service type are supported. Services are managed from the
These do not reference a service.
### Backend Scheduled Actions and qBittorrent Polling
- The backend should collect qBittorrent speed samples independently of browser or dashboard presence.
- Scheduled work should use a typed, explicitly registered action system; arbitrary widgets, SSH commands, and user-provided code must not be executable through the scheduler.
- The first scheduled action is qBittorrent speed sampling. The initial deployment assumes one scheduler-capable backend worker; multiple replicas must not silently duplicate polls.
- qBittorrent polling should be opt-out by default for enabled service instances and configurable per service with a 15-second default interval bounded to 5–300 seconds.
- Sample retention should be configurable by duration and maximum rows, defaulting to 30 minutes and 1,200 rows, with duration bounded to 1–24 hours and the row cap enforced server-side.
- The scheduler should run immediately after startup with per-service staggering, use fixed-delay execution, prevent overlap/backlog, and reconcile configuration changes without a backend restart.
- Poll failures should remain enabled, be persisted, and retry with bounded exponential backoff. A successful scheduled or manual run should clear backoff.
- The qBittorrent widget-data endpoint must become read-only; only the scheduler may contact qBittorrent and append samples.
- The service UI should expose polling settings, current status, stale-data state, a manual `Run now` action, selectable chart windows, and paginated scheduled-action history.
- Scheduled-action runs should use dedicated generic records, retain at most 30 days or 1,000 runs per service/action, and never store secrets or raw credentials.
- Disabling a qBittorrent service pauses polling while retaining history; deleting the service purges its samples and scheduler history through the existing cascade-delete behavior.
- Persistent polling failures should be visible in the service UI and application metrics; a new notification channel is not required for the first release.
### Security
- Service secrets (API keys, tokens, passphrases) are **encrypted at rest** with