Filter bulk unsubscribe to suggested senders

[elie222]

✅ Browser QA passed · QA report

_{Apply rerun-qa to rerun.}

Problem

The periodic inbox health email deep-linked to the bulk unsubscribe page with ?select=suggested, which auto-checked the suggested rows in the full sender table. With dozens of rows it was hard to tell what was selected and what wasn't, and a stray click could silently clobber the selection.

The counts could also disagree. The email computed suggestions over every sender in the window; the page recomputed the same predicate over whichever 50 rows it had loaded. So the email could say one number and the page show another.

Changes

• Suggested filter. New first option in the filter dropdown showing only suggested senders, with a line explaining the rule. Replaces the select-on-load behaviour.
• Suggestions computed server-side. The API takes a suggested flag, pushes the volume and read-rate rules into the SQL HAVING clause, drops the row limit, and runs the same shared ranking function the email uses. Both surfaces now derive from identical input.
• Tighter heuristic. Higher minimum email count, lower read-rate cutoff, ranked by unread volume rather than total volume, and capped so a long list doesn't become unactionable.
• Filter reflected in the URL, so a view survives a refresh and can be shared. The legacy select param still resolves to the filter for links already in inboxes.

Rows keep their queried order, so the table's sort columns still work in the suggested view.

Testing

• Unit tests updated and extended for the new thresholds, the unread-based ranking, and the cap
• Query change smoke-tested against a local Postgres to confirm the new HAVING clause binds and filters correctly
• Lint clean on all changed files

🤖 Generated with Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
inbox-zero	Ignored	Preview	Aug 5, 2026 3:23pm

[cubic-dev-ai]

3 issues found across 11 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/BulkUnsubscribeSection.tsx">

<violation number="1" location="apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/BulkUnsubscribeSection.tsx:194">
P2: The Suggested view can still disagree with the inbox-health email around month boundaries because the new server-side suggestion request uses a 90-day window while the email uses three calendar months. Align the page default and email window (for example, use `subMonths(now, 3)` for the page) so the shared ranking operates on identical input.</violation>
</file>

<file name="apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts">

<violation number="1" location="apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts:1144">
P2: The new URL-backed filter is only read once in the `useState` initializer and is never reconciled with later changes to `searchParams`. This defeats part of the stated goal of the change: once the user switches filters, the tab's filter state (`filtersArray` / the `suggested` flag) is the source of truth for the API call, but the URL becomes the source for Back/Forward navigation. If a user switches from 'Suggested' to 'Unhandled' and then presses the browser Back button, the URL shows `?filter=suggested` while the table still shows Unhandled rows (and vice-versa) — the view and the shareable/refreshable URL disagree. Consider deriving the filter from `searchParams` (or adding a `useEffect` that re-syncs `filter` when the relevant params change) so the UI tracks the URL, rather than initializing state once.</violation>
</file>

<file name="apps/web/app/api/user/stats/newsletters/route.ts">

<violation number="1" location="apps/web/app/api/user/stats/newsletters/route.ts:78">
P2: The suggested filter on the bulk-unsubscribe page and the inbox-health email are intended to produce one identical list (that's the stated goal of this PR), but the two still compute the new SQL HAVING predicate over different inputs. The page always sends `types` (the emails-to-include filter) and a date range into `getSenderEmailStats` (route.ts forces `limit: null` and adds `minEmails`/`maxReadRate`), while the inbox-health email runs the same predicate over a fixed 3-month window with no type filter. So the SQL read-rate/min-emails computation on the page is narrowed by whichever emails-to-include option and date range the user has selected, which changes the qualifying senders and the count. As a result, when a user's include-filter or date range differs from the email's, the email's `suggestionCount` and the page's suggested-row count can still diverge — the parity the change is meant to deliver isn't guaranteed. Consider aligning the two to a single shared window/filter set (or explicitly re-deriving the page's suggested eligibility outside the page's types/date filters) so the email count and page list stay in lockstep.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The Suggested view can still disagree with the inbox-health email around month boundaries because the new server-side suggestion request uses a 90-day window while the email uses three calendar months. Align the page default and email window (for example, use subMonths(now, 3) for the page) so the shared ranking operates on identical input.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/BulkUnsubscribeSection.tsx, line 194:

<comment>The Suggested view can still disagree with the inbox-health email around month boundaries because the new server-side suggestion request uses a 90-day window while the email uses three calendar months. Align the page default and email window (for example, use `subMonths(now, 3)` for the page) so the shared ranking operates on identical input.</comment>

<file context>
@@ -183,13 +182,16 @@ export function BulkUnsubscribe() {
     orderDirection: sortDirection,
     limit: expanded ? 500 : 50,
     includeMissingUnsubscribe: true,
+    ...(isSuggestedFilter ? { suggested: true } : {}),
     ...getDateRangeParams(dateRange),
     ...(search ? { search } : {}),
</file context>

[cubic-dev-ai]

P2: The new URL-backed filter is only read once in the useState initializer and is never reconciled with later changes to searchParams. This defeats part of the stated goal of the change: once the user switches filters, the tab's filter state (filtersArray / the suggested flag) is the source of truth for the API call, but the URL becomes the source for Back/Forward navigation. If a user switches from 'Suggested' to 'Unhandled' and then presses the browser Back button, the URL shows ?filter=suggested while the table still shows Unhandled rows (and vice-versa) — the view and the shareable/refreshable URL disagree. Consider deriving the filter from searchParams (or adding a useEffect that re-syncs filter when the relevant params change) so the UI tracks the URL, rather than initializing state once.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts, line 1144:

<comment>The new URL-backed filter is only read once in the `useState` initializer and is never reconciled with later changes to `searchParams`. This defeats part of the stated goal of the change: once the user switches filters, the tab's filter state (`filtersArray` / the `suggested` flag) is the source of truth for the API call, but the URL becomes the source for Back/Forward navigation. If a user switches from 'Suggested' to 'Unhandled' and then presses the browser Back button, the URL shows `?filter=suggested` while the table still shows Unhandled rows (and vice-versa) — the view and the shareable/refreshable URL disagree. Consider deriving the filter from `searchParams` (or adding a `useEffect` that re-syncs `filter` when the relevant params change) so the UI tracks the URL, rather than initializing state once.</comment>

<file context>
@@ -1123,8 +1125,50 @@ export function useBulkUnsubscribeShortcuts<T extends Row>({
+  const router = useRouter();
+  const pathname = usePathname();
+
+  const [filter, setFilterState] = useState<NewsletterFilterType>(() => {
+    // `select=suggested` is the legacy form used by inbox health emails
+    // already sent out
</file context>

[cubic-dev-ai]

P2: The suggested filter on the bulk-unsubscribe page and the inbox-health email are intended to produce one identical list (that's the stated goal of this PR), but the two still compute the new SQL HAVING predicate over different inputs. The page always sends types (the emails-to-include filter) and a date range into getSenderEmailStats (route.ts forces limit: null and adds minEmails/maxReadRate), while the inbox-health email runs the same predicate over a fixed 3-month window with no type filter. So the SQL read-rate/min-emails computation on the page is narrowed by whichever emails-to-include option and date range the user has selected, which changes the qualifying senders and the count. As a result, when a user's include-filter or date range differs from the email's, the email's suggestionCount and the page's suggested-row count can still diverge — the parity the change is meant to deliver isn't guaranteed. Consider aligning the two to a single shared window/filter set (or explicitly re-deriving the page's suggested eligibility outside the page's types/date filters) so the email count and page list stay in lockstep.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/app/api/user/stats/newsletters/route.ts, line 78:

<comment>The suggested filter on the bulk-unsubscribe page and the inbox-health email are intended to produce one identical list (that's the stated goal of this PR), but the two still compute the new SQL HAVING predicate over different inputs. The page always sends `types` (the emails-to-include filter) and a date range into `getSenderEmailStats` (route.ts forces `limit: null` and adds `minEmails`/`maxReadRate`), while the inbox-health email runs the same predicate over a fixed 3-month window with no type filter. So the SQL read-rate/min-emails computation on the page is narrowed by whichever emails-to-include option and date range the user has selected, which changes the qualifying senders and the count. As a result, when a user's include-filter or date range differs from the email's, the email's `suggestionCount` and the page's suggested-row count can still diverge — the parity the change is meant to deliver isn't guaranteed. Consider aligning the two to a single shared window/filter set (or explicitly re-deriving the page's suggested eligibility outside the page's types/date filters) so the email count and page list stay in lockstep.</comment>

<file context>
@@ -63,7 +73,13 @@ async function getEmailMessages(
-      limit: options.limit,
+      // Suggestions are ranked and capped below, so the row limit would
+      // otherwise decide which senders are eligible
+      limit: options.suggested ? null : options.limit,
+      minEmails: options.suggested ? SUGGESTION_MIN_EMAILS : undefined,
+      maxReadRate: options.suggested
</file context>

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ elie222
❌ gentlemandev
_{You have signed the CLA already but the status is still pending? Let us recheck it.}