apps/web/lib/partnerstack/import-customers.ts (1)

246-249: Error handling needs improvement for production resilience.

The current error handling only logs errors without proper error tracking or recovery mechanisms. This could lead to silent failures during imports.

Based on the existing review comment, this issue has already been identified. The current implementation risks silent data loss during customer imports.

apps/web/lib/partnerstack/import-customers.ts (5)

173-173: Consider the implications of using only the first link.

The logic always uses links[0] without considering that a partner might have multiple relevant links. This could lead to inconsistent click attribution if customers should be associated with different links based on specific criteria.

Consider adding logic to select the most appropriate link:

-  const link = links[0];
+  // Select the most appropriate link (e.g., primary, most recent, or based on other criteria)
+  const link = links.find(l => l.primary) || links[0];

Or document why using the first link is the intended behavior if this is correct.

---

175-183: Avoid hardcoded dummy request headers.

The hardcoded request headers could lead to inconsistent geolocation data and user-agent tracking. Consider making these configurable or using more realistic defaults.

+const DEFAULT_IMPORT_HEADERS = {
+  "user-agent": "PartnerStack-Importer/1.0",
+  "x-forwarded-for": "127.0.0.1",
+  "x-vercel-ip-country": "US",
+  "x-vercel-ip-country-region": "CA", 
+  "x-vercel-ip-continent": "NA",
+};

  const dummyRequest = new Request(link.url, {
-    headers: new Headers({
-      "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)",
-      "x-forwarded-for": "127.0.0.1",
-      "x-vercel-ip-country": "US",
-      "x-vercel-ip-country-region": "CA",
-      "x-vercel-ip-continent": "NA",
-    }),
+    headers: new Headers(DEFAULT_IMPORT_HEADERS),
  });

---

209-213: Improve name fallback logic clarity.

The name fallback logic is complex and could be simplified for better readability.

-        name:
-          // if name is null/undefined or starts with cus_, use email as name
-          !customer.name || customer.name.startsWith("cus_")
-            ? customer.email
-            : customer.name,
+        name: getCustomerDisplayName(customer),

Add a helper function:

+function getCustomerDisplayName(customer: PartnerStackCustomer): string {
+  // If name is null/undefined or starts with cus_, use email as name
+  if (!customer.name || customer.name.startsWith("cus_")) {
+    return customer.email;
+  }
+  return customer.name;
+}

---

107-118: Consider adding batch processing feedback.

The batch processing uses Promise.allSettled but doesn't provide feedback on success/failure rates, which could be valuable for monitoring import health.

-      await Promise.allSettled(
+      const results = await Promise.allSettled(
        customers.map((customer) => {
          const partnerId = partnerKeysToId[customer.partnership_key];
          const links = partnerId ? partnerIdToLinks.get(partnerId) ?? [] : [];

          return createCustomer({
            workspace: program.workspace,
            links,
            customer,
          });
        }),
      );
+
+      const successful = results.filter(r => r.status === 'fulfilled').length;
+      const failed = results.filter(r => r.status === 'rejected').length;
+      
+      if (failed > 0) {
+        console.warn(`Batch ${processedBatches + 1}: ${successful} succeeded, ${failed} failed`);
+      }

---

121-121: Make rate limiting configurable.

The hardcoded 2-second delay might not be optimal for all scenarios and could impact import performance.

+const BATCH_DELAY_MS = 2000; // Make this configurable via environment variable

-    await new Promise((resolve) => setTimeout(resolve, 2000));
+    await new Promise((resolve) => setTimeout(resolve, BATCH_DELAY_MS));

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: devkiran
PR: dubinc/dub#2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.

apps/web/lib/partnerstack/import-partners.ts (1)

75-75: Replace delete operator with more performant approach.

Same performance issue as in the import-links file.

Apply this diff:

-  delete payload?.startingAfter;
+  const { startingAfter: _, ...updatedPayload } = payload;

Then update the queue call:

   await partnerStackImporter.queue({
-    ...payload,
+    ...updatedPayload,
     ...(hasMore && { startingAfter: currentStartingAfter }),
     action: hasMore ? "import-partners" : "import-links",
   });

apps/web/lib/partnerstack/import-commissions.ts (2)

105-117: Clarify the use of commission.key for deduplication.

Using commission.key as invoiceId is confusing and could lead to maintenance issues. The comment acknowledges this isn't the actual invoice ID, which suggests a better approach might be needed.

Consider:

1. Adding a dedicated externalId field to store the PartnerStack commission key
2. Creating a composite unique constraint that better represents the deduplication logic
3. Documenting why this approach was chosen over alternatives

 const commissionFound = await prisma.commission.findUnique({
   where: {
-    invoiceId_programId: {
-      invoiceId: commission.key, // This is not the actual invoice ID, but we use this to deduplicate the commissions
-      programId,
-    },
+    externalId_programId: {
+      externalId: commission.key,
+      programId,
+    },
   },
 });

---

204-265: Ensure data consistency with database transactions.

The commission creation involves multiple related database operations that should be atomic. If any operation fails, the data could be left in an inconsistent state.

Wrap the operations in a database transaction:

-  await Promise.all([
-    prisma.commission.create({
+  await prisma.$transaction(async (tx) => {
+    await Promise.all([
+      tx.commission.create({
         data: {
           // ... commission data
         },
       }),
-
-    recordSaleWithTimestamp({
-      // ... sale event data
-    }),
-
-    // update link stats
-    prisma.link.update({
-      where: {
-        id: customer.linkId,
-      },
-      data: {
-        // ... update data
-      },
-    }),
-
-    // update customer stats
-    prisma.customer.update({
-      where: {
-        id: customer.id,
-      },
-      data: {
-        // ... update data
-      },
-    }),
-  ]);
+      
+      // update link stats
+      tx.link.update({
+        where: {
+          id: customer.linkId,
+        },
+        data: {
+          // ... update data
+        },
+      }),
+      
+      // update customer stats
+      tx.customer.update({
+        where: {
+          id: customer.id,
+        },
+        data: {
+          // ... update data
+        },
+      }),
+    ]);
+    
+    // Record sale event outside transaction if it's an external service
+    await recordSaleWithTimestamp({
+      // ... sale event data
+    });
+  });

Note: If recordSaleWithTimestamp is an external service call, consider whether it should be inside or outside the transaction based on your consistency requirements.

apps/web/lib/partnerstack/import-customers.ts (3)

128-128: Replace delete operator with object destructuring for better performance.

The delete operator can impact performance as it changes the object's hidden class in JavaScript engines.

-  delete payload?.startingAfter;
+  const { startingAfter: _, ...payloadWithoutStartingAfter } = payload;

Then update the queue call:

  await partnerStackImporter.queue({
-    ...payload,
+    ...payloadWithoutStartingAfter,
    ...(hasMore && { startingAfter: currentStartingAfter }),
    action: hasMore ? "import-customers" : "import-commissions",
  });

---

204-204: Add validation for customer.created_at timestamp.

The code assumes customer.created_at exists and is a valid date, but this should be validated to prevent runtime errors.

+  const createdAt = customer.created_at ? new Date(customer.created_at) : new Date();
+  
+  if (customer.created_at && isNaN(createdAt.getTime())) {
+    console.warn(`Invalid created_at timestamp for customer ${customer.email}: ${customer.created_at}`);
+    createdAt = new Date();
+  }

  const clickData = await recordClick({
    req: dummyRequest,
    linkId: link.id,
    clickId: nanoid(16),
    url: link.url,
    domain: link.domain,
    key: link.key,
    workspaceId: workspace.id,
    skipRatelimit: true,
-    timestamp: new Date(customer.created_at).toISOString(),
+    timestamp: createdAt.toISOString(),
  });

---

256-259: Improve error handling for customer creation failures.

The current error handling only logs errors to console without propagating them or tracking failures. This could lead to silent data loss during imports.

Consider:

1. Collecting failed customer imports and returning them to the caller
2. Implementing retry logic for transient failures
3. Recording import failures in a database table for later analysis
4. Using structured logging instead of console.error

-  } catch (error) {
-    console.error("Error creating customer", customer, error);
-  }
+  } catch (error) {
+    // Log with structured data for better monitoring
+    console.error("Failed to create customer", {
+      customerEmail: customer.email,
+      customerKey: customer.customer_key,
+      partnershipKey: customer.partnership_key,
+      error: error instanceof Error ? error.message : String(error),
+    });
+    
+    // Re-throw to let Promise.allSettled handle it
+    throw error;
+  }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: devkiran
PR: dubinc/dub#2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.

Learnt from: devkiran
PR: dubinc/dub#2635
File: packages/prisma/schema/payout.prisma:24-25
Timestamp: 2025-07-11T16:28:55.693Z
Learning: In the Dub codebase, multiple payout records can now share the same stripeTransferId because payouts are grouped by partner and processed as single Stripe transfers. This is why the @unique constraint was removed from the stripeTransferId field in the Payout model - a single transfer can include multiple payouts for the same partner.

Learnt from: devkiran
PR: dubinc/dub#2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.

Learnt from: devkiran
PR: dubinc/dub#2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.