Reviewing files that changed from the base of the PR and between b38eaf1 and b30014b.

• apps/web/lib/api/network/calculate-partner-ranking.ts (6 hunks)

• GitHub Check: build

apps/web/lib/api/network/calculate-partner-ranking.ts (6)

24-44: Excellent documentation of the new scoring system!

The detailed breakdown with concrete examples (2 programs = 50, 3 = 87, etc.) makes the exponential scaling immediately clear. The 0-265+ point range is well-explained and matches the implementation.

---

109-110: LGTM: Sorting logic correctly prioritizes the enhanced finalScore.

The updated ORDER BY clauses appropriately surface high-performing partners while maintaining logical tiebreakers (starredAt, profile presence, ID).

---

145-148: LGTM: Filter definition follows established pattern.

The new multi-program filter correctly reuses the helper function and maintains consistency with the optimization strategy.

---

182-182: Verify the use of totalCommissions vs totalConversions is intentional.

The multi-program bonus uses totalCommissions > 0 as the success metric (lines 182, 194), while the all-program metrics join uses totalConversions > 0 (line 160). This difference may be intentional—commissions represent actual revenue and could be a stronger signal of quality than conversions alone. Please confirm this distinction is deliberate.

Also applies to: 194-194

---

272-279: LGTM: Final score calculation is correct and well-documented.

The calculation properly integrates the new multi-program bonus with proper NULL handling. The order (Bonus + Similarity + Match) reflects the intended priority, and the maximum of 265 points is achievable (200 + 50 + 15).

---

299-300: LGTM: Join integration is correct.

The multiProgramSuccessJoin is properly integrated into the query structure, maintaining consistency with other metric joins.

Reviewing files that changed from the base of the PR and between b30014b and 764fa4f.

• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/network/page-client.tsx (3 hunks)
• apps/web/lib/api/network/calculate-partner-ranking.ts (6 hunks)
• apps/web/ui/partners/partner-info-cards.tsx (2 hunks)
• apps/web/ui/partners/partner-star-button.tsx (1 hunks)

apps/web/ui/partners/partner-info-cards.tsx (1)

182-184: LGTM! Clean integration of the star button.

The conditional rendering and positioning of PartnerStarButton is consistent with the existing PartnerStatusBadgeWithTooltip pattern for enrolled partners. The size-9 className appropriately sizes the button for the card layout.

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/network/page-client.tsx (1)

440-445: LGTM! Effective refactoring to use the shared component.

The migration from an inline Button to PartnerStarButton maintains all existing behavior through the onToggleStarred callback. The custom mutation logic (lines 256-293) with optimistic updates and populateCache is preserved, which is appropriate for this page's specific SWR data management needs.

apps/web/lib/api/network/calculate-partner-ranking.ts (2)

109-110: Verify order-by behavior with starred partners.

The updated order clause for starred discover status now prioritizes starredAt DESC before finalScore DESC (line 109). This means more recently starred partners appear first, regardless of their score. Is this the intended behavior?

If the goal is to show highest-scored starred partners first (ignoring when they were starred), the order should be:

-        ? Prisma.sql`dp.starredAt DESC, finalScore DESC, ${hasProfileCheck} DESC, p.id ASC`
+        ? Prisma.sql`finalScore DESC, ${hasProfileCheck} DESC, p.id ASC`

Otherwise, if recency of starring is important for user workflow (e.g., "I just starred this to review later"), the current order is correct.

---

166-183: Verify multi-program join performance in staging with production-like data.

The code structure appears sound with deliberate optimizations (subquery approach to avoid expensive joins, proper filtering), but actual performance impact cannot be determined without database-level verification. The sandbox environment lacks database access for EXPLAIN plan analysis.

Recommend testing the full ranking query in a staging environment with production-like data volumes to confirm performance characteristics, particularly for scenarios with high volumes of ProgramEnrollment records and diverse partner counts.

apps/web/ui/partners/partner-star-button.tsx (1)

58-63: Add null check before API call.

The non-null assertion on workspaceId! (line 60) could cause a runtime error if useWorkspace returns undefined. While the Button is only rendered when a partner exists, the workspace might still be loading.

Apply this diff to add a guard:

     try {
+      if (!workspaceId) {
+        toast.error("Workspace not found");
+        mutatePrefix("/api/network/partners");
+        return;
+      }
+
       const result = await updateDiscoveredPartner({
-        workspaceId: workspaceId!,
+        workspaceId,
         partnerId: partner.id,
         starred,
       });

⛔ Skipped due to learnings

Learnt from: TWilson023
Repo: dubinc/dub PR: 2538
File: apps/web/ui/partners/overview/blocks/commissions-block.tsx:16-27
Timestamp: 2025-06-18T20:26:25.177Z
Learning: In the Dub codebase, components that use workspace data (workspaceId, defaultProgramId) are wrapped in `WorkspaceAuth` which ensures these values are always available, making non-null assertions safe. This is acknowledged as a common pattern in their codebase, though not ideal.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2736
File: apps/web/lib/swr/use-bounty.ts:11-16
Timestamp: 2025-08-26T15:05:55.081Z
Learning: In the Dub codebase, workspace authentication and route structures prevent endless loading states when workspaceId or similar route parameters are missing, so gating SWR loading states on parameter availability is often unnecessary.