qBittorrent’s Force Resume state — set via right-click → Force Resume in the WebUI, or POST /api/v2/torrents/setForceStart with value=true — overrides every configured share-limit policy. The torrent ignores max_ratio, max_seeding_time, queue caps, and the ShareLimitAction (“Pause” / “Stop”). It keeps seeding regardless of what the global or per-torrent limits say. This is intentional: it’s qBittorrent’s escape hatch for “just keep this one going,” but it makes the configured limits a no-op for any torrent it touches.
The mechanism matters because it breaks downstream automation that depends on torrents reaching a terminal state. In a Sonarr/Radarr + qBittorrent pipeline, the removeCompletedDownloads task watches for paused completed torrents as its signal to delete the qBittorrent entry and reclaim the file in /downloads/. A force-resumed torrent never pauses, so files accumulate indefinitely even after Sonarr imports them to the library. A max_ratio=0 + ShareLimitAction=Stop config — which should auto-cleanup on completion — becomes silently inert for every torrent that’s ever been force-resumed.
The undo is setForceStart with value=false. The torrent drops back to normal queue state, immediately trips the ratio limit, transitions to stoppedUP, and the cleanup task picks it up on its next sweep.