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

690-701: Fix type mismatch in SWR hook.

The useSWR hook is typed as returning a single PartnerNetworkPartnerProps, but line 700 accesses it as an array with fetchedPartners?.[0]. This type mismatch could lead to runtime errors.

Apply this diff to fix the type:

-  const { data: fetchedPartners, isLoading } =
-    useSWR<PartnerNetworkPartnerProps>(
+  const { data: fetchedPartners, isLoading } =
+    useSWR<PartnerNetworkPartnerProps[]>(
       fetchPartnerId &&
         `/api/network/partners?workspaceId=${workspaceId}&partnerIds=${fetchPartnerId}`,
       fetcher,
       {
         keepPreviousData: true,
       },
     );

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

260-296: Document the SWR typing limitation.

The @ts-ignore comment mentions SWR's incomplete typing for populateCache with partial data. While this is a known limitation, consider adding a more detailed comment explaining the expected behavior and why it's safe to ignore.

Apply this diff to improve the comment:

                     mutatePartners(
-                       // @ts-ignore SWR doesn't seem to have proper typing for partial data results w/ `populateCache`
+                       // @ts-ignore SWR's populateCache typing doesn't support partial data results.
+                       // Safe: optimisticData and populateCache both map over the existing array.
                       async () => {

---

584-604: Simplify resize logic dependencies.

The isReady state is reset to false on line 587 but checked for early return on line 585. This creates unnecessary re-renders. Consider simplifying the logic to avoid the redundant state update.

Apply this diff:

   useEffect(() => {
-    if (isReady) return;
-
-    setIsReady(false);
     setShownItems(items);
+    setIsReady(false);
   }, [items]);

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/network/use-partner-network-filters.tsx (1)

156-162: Consider extracting filter keys constant.

The onRemoveAll function hardcodes the multi-filter keys. Consider extracting these to a constant to avoid duplication with the multiFilters object definition.

Add a constant at the top of the hook:

+  const MULTI_FILTER_KEYS = [
+    "industryInterests",
+    "salesChannels", 
+    "preferredEarningStructures",
+  ] as const;
+
   const multiFilters = useMemo(
     () => ({
-      industryInterests:
+      [MULTI_FILTER_KEYS[0]]:
         searchParamsObj.industryInterests?.split(",")?.filter(Boolean) ?? [],
       // ... update other keys similarly
     }),
     [searchParamsObj],
   );

   const onRemoveAll = useCallback(
     () =>
       queryParams({
-        del: [...Object.keys(multiFilters), "country", "starred"],
+        del: [...MULTI_FILTER_KEYS, "country", "starred"],
       }),
     [queryParams],
   );

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/ui/layout/sidebar/app-sidebar-nav.tsx (1)

245-260: Navigation structure looks good.

The updated isActive logic correctly excludes both "applications" and "network" paths, ensuring "All Partners" is active only for the base partners list. The new navigation entries for "Groups" and "Partner Network" are properly structured.

Consider removing the type casting on line 259 if it's not necessary:

-            href: `/${slug}/program/partners/network` as `/${string}`,
+            href: `/${slug}/program/partners/network`,

Other navigation entries don't require this type assertion, so verify if this is addressing a specific TypeScript error or can be safely removed.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/lib/swr/use-network-partners-count.ts (1)

30-42: Handle undefined/array params when building the SWR key.

Passing { workspaceId, ...query } straight into URLSearchParams turns optional fields into "undefined" and flattens arrays incorrectly, so /count rejects the request. Iterate entries, skip undefined/null, and append array items individually before stringifying.

-        ignoreParams
-          ? `?${new URLSearchParams({ workspaceId, ...(query as any) }).toString()}`
+        ignoreParams
+          ? (() => {
+              const params = new URLSearchParams();
+              Object.entries({
+                workspaceId,
+                ...(query as Record<string, unknown>),
+              }).forEach(([key, value]) => {
+                if (value === undefined || value === null) return;
+                if (Array.isArray(value)) {
+                  value.forEach((item) => params.append(key, String(item)));
+                } else {
+                  params.append(key, String(value));
+                }
+              });
+              return `?${params.toString()}`;
+            })()

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

689-699: Fix SWR return type for partner lookup.

/api/network/partners returns an array, yet this hook still types useSWR as NetworkPartnerProps. That undermines type safety (and tooling) and was already flagged earlier. Keep the data typed as an array before indexing.

-  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps>(
+  const { data: fetchedPartners, isLoading } =
+    useSWR<NetworkPartnerProps[]>(
       fetchPartnerId &&
         `/api/network/partners?workspaceId=${workspaceId}&partnerIds=${fetchPartnerId}`,
       fetcher,
       {
         keepPreviousData: true,
       },
     );

apps/web/lib/zod/schemas/partner-network.ts (1)

50-67: Address the empty string filtering issue flagged in previous reviews.

As noted in previous review comments, the preprocess functions split comma-separated strings but don't filter out empty strings. This remains unresolved and can cause enum validation failures when trailing commas are present (e.g., "foo,bar," → ["foo", "bar", ""]).

Apply the suggested fix from the previous review:

     industryInterests: z
       .preprocess(
-        (v) => (typeof v === "string" ? v.split(",") : v),
+        (v) => (typeof v === "string" ? v.split(",").filter(Boolean) : v),
         z.array(z.nativeEnum(IndustryInterest)),
       )
       .optional(),
     salesChannels: z
       .preprocess(
-        (v) => (typeof v === "string" ? v.split(",") : v),
+        (v) => (typeof v === "string" ? v.split(",").filter(Boolean) : v),
         z.array(z.nativeEnum(SalesChannel)),
       )
       .optional(),
     preferredEarningStructures: z
       .preprocess(
-        (v) => (typeof v === "string" ? v.split(",") : v),
+        (v) => (typeof v === "string" ? v.split(",").filter(Boolean) : v),
         z.array(z.nativeEnum(PreferredEarningStructure)),
       )
       .optional(),

apps/web/app/(ee)/api/network/partners/route.ts (1)

84-84: Critical: Division by zero remains unresolved from previous reviews.

As flagged in previous review comments, the division SUM(conversions) / SUM(clicks) will throw a runtime error when SUM(clicks) is 0. The COALESCE wrapper won't help because the division error occurs before COALESCE can act.

Apply the previously suggested fix:

-          COALESCE(SUM(conversions) / SUM(clicks), 0) as conversionRate
+          SUM(conversions) / NULLIF(SUM(clicks), 0) as conversionRate

This will return NULL when clicks are zero, which COALESCE can then handle safely.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

147-147: Remove non-null assertion on discoverableAt.

The non-null assertion (partner.discoverableAt!) remains unaddressed from a previous review. While network partners should have a non-null discoverableAt to be listed, runtime data can be inconsistent.

Apply this diff to handle the null case safely:

             text: partner
-              ? `Joined ${formatDate(partner.discoverableAt!)}`
+              ? partner.discoverableAt
+                ? `Joined ${formatDate(partner.discoverableAt)}`
+                : "Recently joined"
               : undefined,

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-discovery-guide.tsx (1)

16-23: Fix hook order before early return.
useState and usePartnerDiscoveryRequirements sit behind the partner.discoverableAt guard, so hook order changes once a partner becomes discoverable and React throws. Call the hooks unconditionally, then short-circuit on the guard.

-export function ProfileDiscoveryGuide({ partner }: { partner: PartnerProps }) {
-  if (partner.discoverableAt) return null;
-
-  const [isExpanded, setIsExpanded] = useState(false);
-
-  const tasks = usePartnerDiscoveryRequirements();
-
-  if (!tasks) return null;
+export function ProfileDiscoveryGuide({ partner }: { partner: PartnerProps }) {
+  const [isExpanded, setIsExpanded] = useState(false);
+
+  const tasks = usePartnerDiscoveryRequirements();
+
+  if (partner.discoverableAt || !tasks) return null;

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

687-697: Fix SWR typing for partner fetch.

The SWR hook is typed as useSWR<NetworkPartnerProps>, but the code at line 696 accesses fetchedPartners?.[0], indicating the API returns an array. Update the generic type to NetworkPartnerProps[] to match the actual response shape.

Apply this diff:

-  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps>(
+  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps[]>(

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

245-245: Clarify the conditional logic.

The condition !partners || partners?.length is unclear. It evaluates to true when partners is undefined or when the array has any items. The intent appears to be "show content if loading or if there are partners."

Apply this diff for clarity:

-      ) : !partners || partners?.length ? (
+      ) : !partners || partners.length > 0 ? (

Or use explicit boolean conversion:

-      ) : !partners || partners?.length ? (
+      ) : !partners || partners.length > 0 ? (

---

259-296: Consider wrapping optimistic update logic in a helper.

The inline mutatePartners call with complex optimistic update logic reduces readability. While the @ts-ignore comment explains the SWR typing limitation, extracting this pattern into a reusable helper would improve maintainability and reduce repetition if this pattern is used elsewhere.

Consider creating a helper function:

async function togglePartnerStar(
  partnerId: string,
  starred: boolean,
  currentPartners: NetworkPartnerProps[],
) {
  const result = await updateDiscoveredPartner({
    workspaceId: workspaceId!,
    partnerId,
    starred,
  });
  
  if (!result?.data) {
    toast.error("Failed to star partner");
    throw new Error("Failed to star partner");
  }
  
  return {
    result: result.data,
    optimisticData: currentPartners.map((p) =>
      p.id === partnerId ? { ...p, starredAt: starred ? new Date() : null } : p,
    ),
  };
}

Then use it in the mutate call with proper typing.

---

581-610: Clarify the effect dependency chain.

The effects at lines 581-586 and 605-610 form a complex dependency chain:

1. When items change or isReady is false, reset state and set shownItems = items
2. After render, check overflow and trim shownItems (lines 588-601)
3. On resize, if overflow detected, reset isReady to trigger the cycle again (lines 605-610)

This works but is difficult to follow. Consider adding comments or simplifying the logic.

Add inline comments to document the flow:

   useEffect(() => {
+    // Reset shown items when items change or we're not ready
     if (isReady) return;

     setIsReady(false);
     setShownItems(items);
   }, [items, isReady]);

   useEffect(() => {
     if (!containerRef.current) return;

-    // Determine if we need to show less items
+    // Progressively hide items until content fits container width
     if (
       shownItems?.length &&
       containerRef.current.scrollWidth > containerRef.current.clientWidth
     ) {
       setIsReady(false);
       setShownItems(shownItems?.slice(0, -1));
     } else {
       setIsReady(true);
     }
   }, [shownItems]);

-  // Show less items if needed after resizing
+  // Reset ready state on resize to re-trigger overflow check
   const entry = useResizeObserver(containerRef);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

703-713: Fix SWR typing for partner fetch.

The past review comment correctly identified that useSWR<NetworkPartnerProps> should be useSWR<NetworkPartnerProps[]> since line 712 accesses fetchedPartners?.[0], proving the API returns an array.

Apply this diff to fix the typing:

-  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps>(
+  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps[]>(

---

105-113: Remove as any type assertion.

The past review comment correctly identified that the as any assertion on line 140 bypasses TypeScript's discriminated union type checking.

Apply this diff to properly handle the state update:

-          setIsOpen={(open) =>
-            setDetailsSheetState((s) => ({ ...s, open }) as any)
-          }
+          setIsOpen={(open) => {
+            if (!open) {
+              setDetailsSheetState({ open: false, partnerId: null });
+            } else if (detailsSheetState.partnerId) {
+              setDetailsSheetState({ open: true, partnerId: detailsSheetState.partnerId });
+            }
+          }}

Alternatively, simplify the state type:

-  const [detailsSheetState, setDetailsSheetState] = useState<
-    | { open: false; partnerId: string | null }
-    | { open: true; partnerId: string }
-  >({ open: false, partnerId: null });
+  const [detailsSheetState, setDetailsSheetState] = useState<{
+    open: boolean;
+    partnerId: string | null;
+  }>({ open: false, partnerId: null });

Also applies to: 139-141

apps/web/app/(ee)/api/network/partners/route.ts (1)

142-153: Fix division by zero in conversion-rate aggregation.

The past review comment correctly identified that COALESCE(SUM(conversions) / SUM(clicks), 0) on line 146 will raise a division-by-zero error when SUM(clicks) is 0. Use NULLIF to handle this case.

Apply this diff:

-          COALESCE(SUM(conversions) / SUM(clicks), 0) as conversionRate,
+          SUM(conversions) / NULLIF(SUM(clicks), 0) as conversionRate,

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

245-245: Clarify boolean logic for partner rendering.

The condition !partners || partners?.length is correct but hard to parse. It renders the grid when partners is undefined/null (loading) or when partners has items, but shows empty state when partners is an empty array.

Consider adding a comment or extracting to a named variable for clarity:

+      const shouldShowGrid = !partners || partners.length > 0;
-      ) : !partners || partners?.length ? (
+      ) : shouldShowGrid ? (

---

259-296: Document the type assertion more clearly.

The @ts-ignore comment on line 260 mentions SWR typing limitations. The implementation is correct, but the comment could be more specific.

Consider expanding the comment:

-                      // @ts-ignore SWR doesn't seem to have proper typing for partial data results w/ `populateCache`
+                      // @ts-ignore - SWR's types don't properly infer the mutator return type when using populateCache with partial updates
                       async () => {

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

703-713: Fix SWR typing for partner fetch.

The hook types fetchedPartners as NetworkPartnerProps but indexes it as an array on line 712 (fetchedPartners?.[0]). This type mismatch will cause TypeScript errors.

Apply this diff:

-  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps>(
+  const { data: fetchedPartners, isLoading } = useSWR<NetworkPartnerProps[]>(

apps/web/lib/middleware/utils/app-redirect.ts (1)

64-67: Inconsistency between AI summary and code.

The AI-generated summary states the exclusion path changed from "/directory" to "/network", but the visible comment on line 64 mentions "/applications". This discrepancy suggests either:

• The summary is incorrect about which paths were involved in the change
• The change affects multiple paths not fully reflected in the comment
• There's a mismatch between what was changed and what was documented

The code logic itself is correct—the regex pattern (pn_[^\/]+) properly excludes all non-partner-ID paths (including /applications, /network, and /directory).

Optionally, consider making the comment more comprehensive to clarify all special paths being excluded:

-  // Only applies when partnerId starts with "pn_" (exclude /applications)
+  // Only applies when partnerId starts with "pn_" (excludes special paths like /applications, /network, etc.)

apps/web/lib/actions/partners/invite-partner-from-network.ts (4)

23-39: Consider pre-validating tenantId enrollment.

The partner query correctly filters out email-based enrollments, but createAndEnrollPartner also checks for tenantId enrollment (see line 52-61 in create-and-enroll-partner.ts). If the partner has a tenantId that's already enrolled in this program, the action will fail later with a less helpful error.

Consider adding tenantId enrollment check to the partner query:

 prisma.partner.findFirst({
   where: {
     id: partnerId,
     programs: {
       none: {
         programId,
+        OR: [
+          { partner: { email: { not: null } } },
+          { tenantId: { not: null } },
+        ],
       },
     },
   },
 }),

Alternatively, enhance the error message on line 42 to indicate which enrollment type (email or tenantId) caused the conflict.

---

41-42: Clarify error message.

The error message mentions "already enrolled in this program," but the query on line 29-38 already filters out enrolled partners using programs: { none: { programId } }. This condition can only trigger if the partner doesn't exist or lacks an email.

Update the error message to reflect the actual failure cases:

-throw new Error("Partner not found or already enrolled in this program.");
+throw new Error("Partner not found or does not have an email address.");

---

59-75: Consider preserving initial invitation timestamp.

The upsert updates invitedAt to the current timestamp even if the partner was previously invited. This overwrites the original invitation date.

If you need to track the original invitation date, consider preserving it:

 update: {
-  invitedAt: new Date(),
+  // Only update invitedAt if it was null (dismissed and re-invited)
+  invitedAt: {
+    set: new Date(),
+  },
 },

Or add a lastInvitedAt field to track re-invitations while preserving the original timestamp.

---

77-108: Consider logging side effect failures.

The use of Promise.allSettled with waitUntil correctly allows side effects to execute without blocking the response. However, failed side effects (email or audit log) will fail silently.

Add error logging to track failures:

 waitUntil(
-  Promise.allSettled([
+  Promise.allSettled([
     sendEmail({
       subject: `${program.name} invited you to join on Dub Partners`,
       variant: "notifications",
       to: partner.email,
       react: PartnerInvite({
         email: partner.email,
         program: {
           name: program.name,
           slug: program.slug,
           logo: program.logo,
         },
       }),
     }),
 
     recordAuditLog({
       workspaceId: workspace.id,
       programId,
       action: "partner.invited",
       description: `Partner ${enrolledPartner.id} invited from network`,
       actor: user,
       targets: [
         {
           type: "partner",
           id: enrolledPartner.id,
           metadata: enrolledPartner,
         },
       ],
     }),
-  ]),
+  ]).then((results) => {
+    results.forEach((result, idx) => {
+      if (result.status === "rejected") {
+        console.error(
+          `Side effect ${idx === 0 ? 'email' : 'audit log'} failed:`,
+          result.reason
+        );
+      }
+    });
+  }),
 );

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro