fix(automations): make tags field condition operators tag-aware

[s0up4200]

Tags field was comparing the entire comma-separated string instead of individual tags. "Tags - Equals - noHL" would fail to match torrents with tags "cross-seed, noHL, racing" because it compared the full string.

Now all string operators (EQUAL, NOT_EQUAL, CONTAINS, NOT_CONTAINS, STARTS_WITH, ENDS_WITH) check against individual tags. MATCHES (regex) still operates on the full string for flexibility.

Fixes workflow conditions not matching torrents by tag name.

Summary by CodeRabbit

• Bug Fixes

  • Improved tag-based condition evaluation with enhanced matching operators and comparison logic.

• Tests

  • Added comprehensive test coverage for tag-based rule evaluation, including multiple operators and edge cases.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The changes modify tag field evaluation in the automations evaluator, replacing string-based comparison with set-based, tag-aware comparison logic. New utility functions support multiple operators (Equal, NotEqual, Contains, NotContains, StartsWith, EndsWith) with case-insensitive tag matching. Comprehensive tests validate the new tag evaluation behavior across various scenarios.

Changes

Cohort / File(s)	Summary
Tag Comparison Logic internal/services/automations/evaluator.go	Modified evaluateLeaf to use compareTags instead of compareString for FieldTags branch. Added new tag-based utilities: compareTags (handles regex/matcher vs. set-based checks), anyTagMatches (predicate helper), tagContains, tagStartsWith, tagEndsWith (case-insensitive matching), and splitTags (parses comma-separated tags).
Tag Evaluation Tests internal/services/automations/evaluator_test.go	Added comprehensive test suite TestEvaluateCondition_Tags validating tag-based rule evaluation across all supported operators (Equal, NotEqual, Contains, NotContains, StartsWith, EndsWith, Matches) with scenarios covering exact matches, case-insensitivity, empty values, whitespace handling, multi-tag strings, and negation behavior.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 Hark! The tags now dance with grace,
Set-based matching wins the race,
No more strings in simple jest,
Case-insensitive beats the rest—
Tests galore ensure it's right, ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 76.92% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and concisely describes the main change: making tag field condition operators tag-aware instead of string-based comparison.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/workflow-tags-condition-matching

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

internal/services/automations/evaluator.go (1)

537-568: Solid tag-aware implementation with one edge case to consider.

The function correctly:

• Preserves regex matching on the full string for flexibility
• Splits tags and evaluates individual tags for string operators
• Uses case-insensitive matching throughout

One edge case: if cond.Value is empty or whitespace-only, condValue becomes "" (line 550). For CONTAINS, STARTS_WITH, and ENDS_WITH operators, Go's strings.Contains/HasPrefix/HasSuffix return true when searching for an empty string, causing all tags to match. Consider adding an early return:

🔎 Optional guard for empty condition values

 func compareTags(tagsRaw string, cond *RuleCondition) bool {
 	// Regex matching operates on full string for flexibility
 	if cond.Regex || cond.Operator == OperatorMatches {
 		if cond.Compiled == nil {
 			return false
 		}
 		return cond.Compiled.MatchString(tagsRaw)
 	}
 
 	tags := splitTags(tagsRaw)
 	condValue := strings.ToLower(strings.TrimSpace(cond.Value))
+	
+	// Return false for empty condition values to avoid unexpected matches
+	if condValue == "" {
+		return false
+	}
 
 	switch cond.Operator {

This behavior may be acceptable if upstream validation prevents empty values, and it mirrors the existing compareString behavior.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6403b6a and f4c7303.

📒 Files selected for processing (2)

• internal/services/automations/evaluator.go
• internal/services/automations/evaluator_test.go

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-12-28T18:44:10.496Z

Learnt from: s0up4200
Repo: autobrr/qui PR: 876
File: internal/logstream/hub_test.go:188-192
Timestamp: 2025-12-28T18:44:10.496Z
Learning: In Go 1.25 (Aug 2025), use wg.Go(func()) to spawn a goroutine and automate the Add/Done lifecycle. Replace manual patterns like wg.Add(1); go func(){ defer wg.Done(); ... }() with wg.Go(func(){ ... }). Ensure the codebase builds with Go 1.25+ and apply this in relevant Go files (e.g., internal/logstream/hub_test.go). If targeting older Go versions, maintain the existing pattern.

Applied to files:

• internal/services/automations/evaluator_test.go
• internal/services/automations/evaluator.go

🔇 Additional comments (4)

internal/services/automations/evaluator.go (3)

284-284: LGTM! Core integration looks correct.

The switch from compareString to compareTags properly enables tag-aware evaluation for the FieldTags branch.

---

570-593: LGTM! Helper functions are clean and correct.

The implementation is straightforward:

• anyTagMatches uses a standard iteration pattern with early return
• Tag matching helpers (tagContains, tagStartsWith, tagEndsWith) correctly perform case-insensitive comparisons
• condValue is already lowercased by the caller, so only the tag needs lowercasing in helpers

---

698-712: LGTM! Robust tag parsing implementation.

The function correctly:

• Returns nil for empty/whitespace input (avoiding [""])
• Splits on comma and trims whitespace from each tag
• Filters out empty parts (handles trailing commas, multiple consecutive commas)
• Pre-allocates the result slice for efficiency

internal/services/automations/evaluator_test.go (1)

1557-1868: Excellent test coverage for the tag-aware evaluation fix.

The test suite comprehensively validates the core fix described in the PR:

• Line 1566: Key test - "noHL" now correctly matches within "cross-seed, noHL, racing" (previously failed when comparing full string)
• Lines 1596-1604: Confirms partial tag names don't match (e.g., "cross" ≠ "cross-seed")
• Lines 1826-1857: Verifies regex operators still operate on the full string for flexibility

The test coverage includes:

• All tag-aware operators (EQUAL, NOT_EQUAL, CONTAINS, NOT_CONTAINS, STARTS_WITH, ENDS_WITH)
• Edge cases (empty tags, whitespace-only, case insensitivity, tags with spaces, leading/trailing spaces)
• Regex behavior preservation (word boundaries, anchors, regex flag)

This directly addresses the bug described in the PR objectives where "Tags - Equals - noHL" failed for torrents with "cross-seed, noHL, racing".