feat: improve member query (CM-764)

[ulemons]

Query Optimization — Extracted Builder & Smarter Execution Paths

Summary

• Refactored queryMembersAdvanced to delegate SQL construction to a new queryBuilder module.
• Moved all complex query logic (filters, search, ordering, joins) into a dedicated builder for better maintainability and safer optimizations.
• Introduced specialized execution paths to improve performance for common scenarios.

---

Key Changes

• New module exports:
  • buildQuery — main data query supporting multiple optimized paths.
  • buildCountQuery — lightweight query for counting members, without unnecessary joins.
• Added member_search and member_orgs CTEs only when required.
• Introduced a clear and safe mapping for ORDER BY fields with sensible defaults.

---

Execution Paths in buildQuery

1️⃣ Direct ID Path (useDirectIdPath)

• filterString pins m.id to a single value or a small list (≤ ~100)
• Queries start directly from memberSegmentsAgg (msa)
• Minimal joins (members, optional member_orgs / memberEnrichments)

---

2️⃣ ActivityCount-Optimized Path

• Sorting by activityCount (or no explicit orderBy)
• No filters on me.*
• Builds a top_members CTE selecting best members by msa."activityCount" (with oversampling)
• This is the main optimization path — reduces load and latency for active-member views.

---

3️⃣ Generic Fallback Path

• Any other case (different sort, me.* filters, no aggregates, etc.)

---

Count Query

• buildCountQuery generates a minimal COUNT(DISTINCT m.id) query.
• Includes only the necessary joins and CTEs (msa, member_orgs, or member_search when relevant).

---

Why This Matters

• Performance: avoids unnecessary joins and top-N operations when IDs are pinned.
• Efficiency: pushes ranking to msa (indexed) and filters externally to keep pages filled.
• Maintainability: clear separation of query-building logic, easier to test and evolve.
• Safety: smart defaults and fallback paths prevent invalid SQL and keep ordering consistent.

---

Note

Extracts a query builder and data processors, adding optimized execution paths and streamlined search/filter/order logic for member queries with parallelized related-data loading.

• Core (members):
  • Refactors queryMembersAdvanced to use buildSearchCTE, buildQuery, and buildCountQuery from members/queryBuilder with default orderBy = activityCount_DESC.
  • Adds optimized paths: direct ID targeting, activityCount top-N, and a fallback path; parameterizes search and trims unnecessary joins in count queries.
  • Validates/filters selected fields against QUERY_FILTER_COLUMN_MAP; tweaks activityCount mapping to msa."activityCount".
  • Parallelizes fetching for identities, segments, organizations, and maintainer roles; adds concise logging; minor typing fix for moveAffiliationsBetweenMembers.
• Data processing:
  • Introduces members/dataProcessor with sortActiveOrganizations, fetchOrganizationData (orgs + LFX), and fetchSegmentData; used to assemble member.organizations and member.segments.
• Cleanup:
  • Removes ad‑hoc SQL construction and inline org/segment lookups from members/base.ts; drops unused imports; streamlines enums/column arrays.

^{Written by Cursor Bugbot for commit c65997d. This will update automatically on new commits. Configure here.}

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Bug: Data Exposure: Attributes Unfiltered

The refactoring removed attribute filtering logic that previously limited returned attributes to avatarUrl, isBot, isTeamMember, and jobTitle. Now all attributes in m.attributes are returned unfiltered. This unintentional behavior change could expose unexpected data or break consumers expecting the filtered subset.