fix(performance): eliminate N+1 query in TagsController#index

[sentry]

This PR resolves an N+1 query issue identified in TagsController#index.
The problem occurred because the app/views/tags/_tag.html.erb partial was calling tag.transactions.any? for each tag without the transactions association being eager-loaded. This resulted in a separate database query for every tag to check for associated transactions.

The fix involves modifying the index action in TagsController to eager-load the transactions association. By changing Current.family.tags.alphabetically to Current.family.tags.includes(:transactions).alphabetically, all necessary transaction data is fetched in a single query, thereby eliminating the N+1 query.

Fixes SURE-APP-168

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 70b2a9d8a7

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Avoid loading every tagged transaction

For families where a tag is attached to many transactions, includes(:transactions) makes the tags settings page instantiate every matching Transaction record even though the partial only needs tag.transactions.any? to choose the delete flow. That replaces a set of indexed existence checks with loading the full tagged transaction history, so large accounts can see worse latency/memory or timeouts; preload/count taggings or expose a boolean instead.

Useful? React with 👍 / 👎.

[jjmata]

Review

Verified the fix targets the right spot: app/views/tags/_tag.html.erb:13 calls tag.transactions.any? inside the per-tag loop, so without eager loading that's one query per tag. Adding .includes(:transactions) loads all of them in a single query, and any? on an already-loaded association reads the in-memory array rather than issuing SELECT ... EXISTS.

Scoped to exactly the one line that needs it, no behavior change otherwise. Looks correct.

One minor, non-blocking note: includes(:transactions) loads full transaction rows just to test presence, which is heavier than a left_joins(:transactions).distinct / counter-cache would be for tags with many transactions — but that's a pre-existing tradeoff in the codebase's N+1-fix pattern, not a regression introduced here.

---

Generated by Claude Code