Problem
The tracker scope of an automation rule (trackerPattern) can match a different set of torrents than the tracker conditions (TRACKER, TRACKERS) of the same rule.
collectTrackerDomains in internal/services/automations/service.go builds the scope domains from Torrent.Tracker and from Torrent.Trackers. A run fills Torrent.Trackers only when the rule has a tracker condition (hydrateTorrentTrackersForRule, through previewNeeds). Thus:
- A rule with a tracker scope and no tracker condition sees only the tracker in use (
Torrent.Tracker). - The same rule with any tracker condition added sees every tracker URL of each torrent.
On develop, the tracker conditions load the full tracker list (HydrateTorrentTrackers). With #3349, they read every URL from the MainData trackers map on qBittorrent 5.1+ (AttachTrackerURLs). In both cases, trackerCandidates in evaluator.go compares the URL, the domain, and the display name.
Effect for the user
A torrent lists tracker A (in use) and tracker B. A rule scoped to B with no tracker condition skips the torrent. Add a TRACKER_STATUS condition that matches the torrent, and the rule now acts on it. A change to the conditions changes the scope.
History
- #818 (December 2025): runs never loaded the tracker list, so the scope always read only the tracker in use.
- #2006 (19 June 2026): rules with
TRACKER_STATUSorTRACKER_MESSAGEload the list. From this change on, the scope depends on the conditions. - #2487 (1 September 2026):
TRACKERandTRACKERSalso load the list, so most rules that name a tracker get the wider scope.
No user reported this. The case needs a torrent with more than one tracker, a scope that names a tracker that is not in use, and a rule with no tracker condition. Priority: low.
Scope note
#3349 keeps this verdict exactly as it is on develop. The fix is a separate decision: either the scope reads every URL on 5.1+, or the scope always reads only the tracker in use. Each choice changes which torrents some existing rules act on.
Activity
0No activity yet.