Reviewing files that changed from the base of the PR and between ac82184 and bf5f4b4.

• apps/web/lib/rewardful/import-commissions.ts (7 hunks)
• apps/web/lib/tinybird/get-lead-events.ts (1 hunks)
• apps/web/scripts/backfill-customers.ts (1 hunks)

• GitHub Check: build

apps/web/scripts/backfill-customers.ts (1)

5-5: Clean refactor to use the shared getLeadEvents module.

The import statement correctly references the new shared module, eliminating code duplication while maintaining the existing functionality of the backfill script.

apps/web/lib/rewardful/import-commissions.ts (5)

5-5: Appropriate imports for the batch processing refactor.

The new imports support the performance optimization:

• Customer, Link types for the prefetched data structures
• getLeadEvents from the new shared module
• LeadEventTB type for the lead events array

Also applies to: 9-9, 12-12

---

55-70: Excellent performance optimization with batch data fetching.

This change eliminates the N+1 query problem by:

1. Prefetching all customers for the current batch of commissions
2. Bulk fetching lead events for all customers at once
3. Passing the prefetched data to avoid repeated queries

The implementation correctly extracts Stripe customer IDs from commissions, filters out null values, and includes the related link data needed downstream.

---

138-139: Updated function signature to support batch processing.

The createCommission function now accepts the prefetched datasets as parameters, enabling in-memory lookups instead of individual database queries. The type annotations correctly reflect the data structures with included relations.

Also applies to: 146-147

---

250-253: Efficient in-memory lookup replaces database query.

The customer lookup now uses the prefetched customersData array instead of a Prisma query, significantly improving performance by eliminating database round trips.

---

303-305: Streamlined lead event processing with prefetched data.

The changes correctly:

1. Use array lookup instead of API call for lead events (lines 303-305)
2. Simplify the existence check by removing the data length validation (line 307)
3. Parse the lead event object directly instead of accessing data[0] (line 321)

This maintains the same validation logic while leveraging the batch-fetched data for better performance.

Also applies to: 307-307, 321-321

Reviewing files that changed from the base of the PR and between bf5f4b4 and ac92db0.

• packages/email/src/templates/program-imported.tsx (1 hunks)
• pipes/get_lead_events.pipe (1 hunks)

• packages/email/src/templates/program-imported.tsx

• GitHub Check: build

pipes/get_lead_events.pipe (2)

1-2: LGTM! Token definition follows best practices.

The read-only token is appropriately scoped for a data fetching endpoint.

---

14-17: LGTM! Proper endpoint type definition.

The endpoint type is correctly specified for HTTP access, and the file structure follows Tinybird conventions.

Reviewing files that changed from the base of the PR and between ac82184 and ac92db0.

• apps/web/lib/rewardful/import-commissions.ts (7 hunks)
• apps/web/lib/tinybird/get-lead-events.ts (1 hunks)
• apps/web/scripts/backfill-customers.ts (1 hunks)
• packages/email/src/templates/program-imported.tsx (1 hunks)
• pipes/get_lead_events.pipe (1 hunks)

packages/email/src/templates/program-imported.tsx (1)

66-66: LGTM! API path restructuring implemented correctly.

The addition of "workspaces" to the download URL path aligns with the broader API restructuring mentioned in the PR objectives.

pipes/get_lead_events.pipe (1)

1-16: LGTM! Well-structured Tinybird pipe definition.

The pipe correctly implements:

• Proper token definition with READ permissions
• Conditional filtering by customerIds array using Tinybird's templating syntax
• Appropriate ordering by timestamp DESC for recent events first
• Clean SQL structure that selects all columns from dub_lead_events

apps/web/scripts/backfill-customers.ts (1)

5-5: LGTM! Clean refactor to use shared module.

The extraction of getLeadEvents from inline definition to a shared module promotes code reuse and maintainability, while keeping the same functionality.

apps/web/lib/tinybird/get-lead-events.ts (1)

1-11: LGTM! Well-implemented type-safe Tinybird pipe wrapper.

The module correctly implements:

• Proper pipe name matching the Tinybird pipe definition
• Type-safe parameter validation with Zod schema for customerIds array
• Appropriate data schema using leadEventSchemaTB
• Clean module structure following established patterns

apps/web/lib/rewardful/import-commissions.ts (4)

250-253: LGTM! Efficient in-memory customer lookup.

The replacement of individual Prisma queries with in-memory lookups using the pre-fetched customersData array significantly improves performance by eliminating N+1 database queries.

---

303-305: LGTM! Efficient in-memory lead event lookup.

The replacement of individual getLeadEvent calls with in-memory lookups using the pre-fetched customerLeadEvents array eliminates N+1 API calls and improves performance significantly.

---

307-321: LGTM! Correct handling of lead event data structure.

The logic correctly handles the lead event lookup and parsing:

• Proper existence check for leadEvent
• Updated parsing to use leadEvent directly instead of leadEvent.data
• Maintains existing validation and error handling flow

---

55-70: Add robust error and edge‐case handling around batch fetch

Please update lines 55–70 of apps/web/lib/rewardful/import-commissions.ts to guard against failures and empty results when fetching customers and lead events:

• Wrap both prisma.customer.findMany and getLeadEvents in a try/catch so one bad batch won’t crash the entire import loop.
• Before calling getLeadEvents, check for an empty customersData array and skip or short-circuit that batch.
• Validate that the response from getLeadEvents actually has a data property before using it.

Suggested diff:

@@ apps/web/lib/rewardful/import-commissions.ts
-    const customersData = await prisma.customer.findMany({
+    try {
+      const customersData = await prisma.customer.findMany({
         where: {
           stripeCustomerId: {
             in: commissions
               .map((commission) => commission.sale.referral.stripe_customer_id)
               .filter(Boolean),
           },
         },
         include: { link: true },
-    const customerLeadEvents = await getLeadEvents({
-      customerIds: customersData.map((customer) => customer.id),
-    }).then((res) => res.data);
+      });
+
+      if (customersData.length === 0) {
+        // No matching customers; skip this batch
+        continue;
+      }
+
+      const response = await getLeadEvents({
+        customerIds: customersData.map((c) => c.id),
+      });
+
+      if (!response?.data) {
+        throw new Error('Unexpected getLeadEvents response');
+      }
+
+      const customerLeadEvents = response.data;
+    } catch (error) {
+      console.error(`Batch fetch failed at page ${currentPage}:`, error);
+      // move on to next batch without halting the import
+      continue;
+    }

Please verify that:

• Your loop variables (currentPage, processedBatches, etc.) still align with this flow.
• getLeadEvents always returns an object with a data field in all success cases.