fix(dashboard): merge tracker customizations with duplicate displayName

[jabloink]

when creating a tracker customization with a name that already exists, it now merges the new domains into the existing customization instead of creating a duplicate entry

previously this would create two individual entries which can be seen by exporting, since its being deduped by displayName, one would disappear and the remaining one wouldnt have a chainlink icon and editing it wouldnt show the urls of the other entry

Summary by CodeRabbit

• Bug Fixes
  • Improved tracker customization consolidation: customizations with matching display names are now automatically merged rather than creating duplicates. When you create a customization with a display name that already exists, the system combines the new domains with the existing entry instead of creating a separate customization. This reduces clutter and improves overall organization of your tracker settings.

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

[coderabbitai]

Walkthrough

The TrackerBreakdownCard component's customization creation logic now conditionally merges domains into existing customizations when a matching case-insensitive displayName is found, instead of always creating new entries. Non-matching customizations fall back to the original creation behavior.

Changes

Cohort / File(s)	Summary
Tracker customization consolidation web/src/pages/Dashboard.tsx	Modified TrackerBreakdownCard logic to check for existing customizations by displayName; if found, merges domains via updateCustomization; otherwise creates new customization.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Focus areas: Logic for case-insensitive displayName matching and domain merging conditions
• Potential concerns: Data consistency implications when merging domains into existing customizations; ensure success handler and dialog closure work correctly for both update and create paths
• Testing: Verify behavior with duplicate displayNames (different cases), empty domain merges, and failure scenarios

Possibly related PRs

• PR #717: Updates FilterSidebar to consume and group tracker customizations by consolidated displayNames, complementing this PR's consolidation logic

Suggested labels

enhancement, web

Poem

🐰 Duplicate names no more shall stay,
We merge them all in one neat way,
Domains consolidated with care,
No fragmentation floating in air!
One customization to bind them true,
Making trackers gleam brand-new!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% 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 accurately and concisely summarizes the main change: merging tracker customizations with duplicate displayName instead of creating duplicates.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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)

web/src/pages/Dashboard.tsx (1)

1094-1130: Solid implementation of the merge-on-duplicate behavior.

The case-insensitive comparison for displayName is correct and addresses the PR objective. A few observations:

1. Domain deduplication: Line 1106 concatenates domains without deduplicating. Per retrieved learnings, the backend's normalizeDomains handler performs deduplication, so this works correctly. However, deduplicating client-side would make intent explicit and reduce payload size:

       if (existing) {
         // Merge into existing
+        const mergedDomains = [...new Set([...existing.domains, ...domains])]
         updateCustomization.mutate(
           {
             id: existing.id,
             data: {
               displayName: existing.displayName,
-              domains: [...existing.domains, ...domains],
+              domains: mergedDomains,
             },
           },

2. User feedback: Consider adding a toast to inform users when domains are merged into an existing customization versus creating a new one—this helps avoid confusion if they expected a separate entry.

Both points are optional improvements; the current implementation is functionally correct. Based on learnings, domain normalization at the API boundary ensures duplicates won't persist.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a9c7754 and a07bf76.

📒 Files selected for processing (1)

• web/src/pages/Dashboard.tsx (1 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: s0up4200
Repo: autobrr/qui PR: 637
File: web/src/pages/Dashboard.tsx:805-831
Timestamp: 2025-11-25T11:39:54.748Z
Learning: In web/src/pages/Dashboard.tsx, the TrackerIconImage component intentionally receives displayDomain (incognito-mapped name) instead of the real domain in incognito mode. This causes icon lookups to fail and show only fallback letters, which is desired behavior for privacy - hiding both tracker names and icons when incognito mode is enabled.

Learnt from: s0up4200
Repo: autobrr/qui PR: 637
File: internal/api/handlers/tracker_customizations.go:138-154
Timestamp: 2025-12-07T21:15:46.214Z
Learning: In the qui codebase (internal/api/handlers/tracker_customizations.go and internal/models/tracker_customization.go), domain normalization follows a layered pattern: the handler's normalizeDomains performs input sanitization at the API boundary (trim, lowercase, deduplicate), while the store's joinDomains is only for serialization. All domains flow through the handler first, ensuring they're normalized before reaching the store layer.

📚 Learning: 2025-11-25T11:39:54.748Z

Learnt from: s0up4200
Repo: autobrr/qui PR: 637
File: web/src/pages/Dashboard.tsx:805-831
Timestamp: 2025-11-25T11:39:54.748Z
Learning: In web/src/pages/Dashboard.tsx, the TrackerIconImage component intentionally receives displayDomain (incognito-mapped name) instead of the real domain in incognito mode. This causes icon lookups to fail and show only fallback letters, which is desired behavior for privacy - hiding both tracker names and icons when incognito mode is enabled.

Applied to files:

• web/src/pages/Dashboard.tsx

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Run tests

[s0up4200]

Thank you, this is good 👍