Reviewing files that changed from the base of the PR and between 20fb776 and f66e25a.

• apps/web/app/(ee)/api/cron/aggregate-clicks/route.ts (1 hunks)
• apps/web/app/(ee)/api/cron/usage/update-partner-stats/route.ts (1 hunks)
• apps/web/app/(ee)/api/partners/route.ts (2 hunks)
• apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (2 hunks)
• apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (2 hunks)
• apps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts (2 hunks)
• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/partners-table.tsx (5 hunks)
• apps/web/lib/actions/partners/create-manual-commission.ts (2 hunks)
• apps/web/lib/api/conversions/track-lead.ts (2 hunks)
• apps/web/lib/api/conversions/track-sale.ts (3 hunks)
• apps/web/lib/api/partners/get-partners-new.ts (1 hunks)
• apps/web/lib/api/partners/sync-partner-links-stats.ts (1 hunks)
• apps/web/lib/api/partners/sync-total-commissions.ts (2 hunks)
• apps/web/lib/firstpromoter/import-commissions.ts (2 hunks)
• apps/web/lib/firstpromoter/import-customers.ts (4 hunks)
• apps/web/lib/integrations/shopify/create-sale.ts (2 hunks)
• apps/web/lib/partners/create-partner-commission.ts (2 hunks)
• apps/web/lib/partnerstack/import-commissions.ts (2 hunks)
• apps/web/lib/partnerstack/import-customers.ts (4 hunks)
• apps/web/lib/rewardful/import-commissions.ts (2 hunks)
• apps/web/lib/rewardful/import-customers.ts (3 hunks)
• apps/web/lib/tolt/import-commissions.ts (2 hunks)
• apps/web/lib/tolt/import-customers.ts (5 hunks)
• apps/web/lib/upstash/redis-streams.ts (1 hunks)
• apps/web/lib/zod/schemas/partners.ts (2 hunks)
• apps/web/scripts/partners/aggregate-stats.ts (1 hunks)
• packages/prisma/schema/program.prisma (1 hunks)

• GitHub Check: build

apps/web/scripts/partners/aggregate-stats.ts (2)

1-77: LGTM! Well-structured PoC script.

The script correctly segregates partner activity events into linkStats and commissionStats categories, preparing them for separate aggregation queries. The use of Set to deduplicate program-partner pairs is appropriate.

---

78-169: LGTM! Aggregation logic is sound.

The script correctly:

• Aggregates link stats (clicks, leads, conversions, sales, saleAmount) using groupBy.
• Aggregates commission stats (earnings) with appropriate filters (non-zero earnings and valid statuses).
• Merges both sets of stats into a unified map before output.

apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (1)

5-5: LGTM! Stats sync correctly integrated.

The syncPartnerLinksStats call is appropriately placed within the sale processing flow and parallelized with workflow execution using Promise.allSettled, ensuring partner link statistics are updated without blocking the primary flow.

Also applies to: 456-460

apps/web/lib/tolt/import-commissions.ts (1)

10-10: LGTM! Stats sync integrated into import flow.

The syncPartnerLinksStats call is correctly placed in the commission creation flow, ensuring partner stats are synchronized during the Tolt import process. Running in parallel with other database operations is appropriate.

Also applies to: 380-384

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

10-10: LGTM! Stats sync integrated into Rewardful import.

The syncPartnerLinksStats call is correctly integrated into the Rewardful commission creation flow, maintaining consistency with other import modules.

Also applies to: 373-377

packages/prisma/schema/program.prisma (1)

99-107: LGTM! Well-designed schema extension.

The new total* fields are properly structured with:

• Clear naming convention using the "total" prefix
• Appropriate default values (0) to avoid null handling
• Logical grouping under a "partner stats" comment section
• Consistency with aggregation logic seen in other parts of the PR

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

8-8: LGTM! Stats sync integrated into PartnerStack import.

The syncPartnerLinksStats call is correctly integrated into the PartnerStack commission creation flow, maintaining consistency with other import modules.

Also applies to: 366-370

apps/web/lib/firstpromoter/import-commissions.ts (1)

10-10: LGTM! Stats sync integrated into FirstPromoter import.

The syncPartnerLinksStats call is correctly integrated into the FirstPromoter commission creation flow, maintaining consistency with other import modules. The use of Promise.allSettled is appropriate for handling parallel side-effects.

Also applies to: 373-377

apps/web/lib/integrations/shopify/create-sale.ts (1)

157-175: Consider logging failures from Promise.allSettled.

Promise.allSettled silently swallows rejections. If either executeWorkflows or syncPartnerLinksStats fails, you won't see any error logs or alerts. This can mask issues in production.

Consider adding error logging:

     waitUntil(
-      Promise.allSettled([
+      Promise.allSettled([
         executeWorkflows({
           trigger: WorkflowTrigger.saleRecorded,
           context: {
             programId: link.programId,
             partnerId: link.partnerId,
             current: {
               saleAmount: saleData.amount,
               conversions: firstConversionFlag ? 1 : 0,
             },
           },
         }),
         syncPartnerLinksStats({
           partnerId: link.partnerId,
           programId: link.programId,
           eventType: "sale",
         }),
-      ]),
+      ]).then((results) => {
+        results.forEach((result, index) => {
+          if (result.status === "rejected") {
+            console.error(
+              `Failed to ${index === 0 ? "execute workflows" : "sync partner stats"}:`,
+              result.reason
+            );
+          }
+        });
+      }),
     );

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

21-26: LGTM! Performance monitoring added.

The console.time/timeEnd calls provide useful insights for optimizing this endpoint.

---

28-50: LGTM! Backward compatibility handled correctly.

The approach ensures existing API consumers continue to work while transitioning to the new total* field naming convention. The use of Zod schema extension with defaults provides type safety.

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

224-253: Consider logging failures from Promise.allSettled.

Similar to other files in this PR, Promise.allSettled will silently ignore failures. Since this is in an import flow, silent failures could lead to inconsistent partner statistics without visibility.

Add error logging to catch and report failures:

   await Promise.allSettled([
     recordLeadWithTimestamp({
       ...clickEvent,
       event_id: nanoid(16),
       event_name: "Sign up",
       customer_id: customerId,
       timestamp: new Date(referral.became_lead_at).toISOString(),
     }),

     prisma.link.update({
       where: { id: link.id },
       data: {
         leads: { increment: 1 },
         lastLeadAt: updateLinkStatsForImporter({
           currentTimestamp: link.lastLeadAt,
           newTimestamp: new Date(referral.became_lead_at),
         }),
       },
     }),
     // partner links should always have a partnerId and programId, but we're doing this to make TS happy
     ...(link.partnerId && link.programId
       ? [
           syncPartnerLinksStats({
             partnerId: link.partnerId,
             programId: link.programId,
             eventType: "lead",
           }),
         ]
       : []),
-  ]);
+  ]).then((results) => {
+    results.forEach((result, index) => {
+      if (result.status === "rejected") {
+        console.error(
+          `[importCustomers] Operation ${index} failed:`,
+          result.reason
+        );
+      }
+    });
+  });

apps/web/lib/actions/partners/create-manual-commission.ts (1)

521-542: Consider logging failures from Promise.allSettled.

The parallel execution is appropriate, but Promise.allSettled silently handles rejections. In the context of manual commission creation, failures in workflow execution or stats syncing should be visible to help debug issues.

Add error logging:

         if (["lead", "sale"].includes(commissionType)) {
-          await Promise.allSettled([
+          const results = await Promise.allSettled([
             executeWorkflows({
               trigger:
                 commissionType === "lead"
                   ? WorkflowTrigger.leadRecorded
                   : WorkflowTrigger.saleRecorded,
               context: {
                 programId,
                 partnerId,
                 current: {
                   leads: commissionType === "lead" ? 1 : 0,
                   saleAmount: saleAmount ?? totalSaleAmount,
                   conversions: firstConversionFlag ? 1 : 0,
                 },
               },
             }),
             syncPartnerLinksStats({
               partnerId,
               programId,
               eventType: commissionType as "lead" | "sale",
             }),
           ]);
+
+          results.forEach((result, index) => {
+            if (result.status === "rejected") {
+              console.error(
+                `[createManualCommission] Failed to ${index === 0 ? "execute workflows" : "sync partner stats"}:`,
+                result.reason
+              );
+            }
+          });
         }

apps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts (1)

139-157: Consider logging failures from Promise.allSettled.

The parallel execution pattern is consistent with the PR's approach, but Promise.allSettled won't log failures. This is particularly important for webhook processing where silent failures can be hard to debug.

Add error logging:

   waitUntil(
-    Promise.allSettled([
+    Promise.allSettled([
       sendWorkspaceWebhook({
         trigger: "lead.created",
         workspace,
         data: transformLeadEventData({
           ...clickData,
           eventName,
           link: linkUpdated,
           customer,
           partner: webhookPartner,
           metadata: null,
         }),
       }),

       ...(link.programId && link.partnerId
         ? [
             executeWorkflows({
               trigger: WorkflowTrigger.leadRecorded,
               context: {
                 programId: link.programId,
                 partnerId: link.partnerId,
                 current: {
                   leads: 1,
                 },
               },
             }),
             syncPartnerLinksStats({
               partnerId: link.partnerId,
               programId: link.programId,
               eventType: "lead",
             }),
           ]
         : []),
-    ]),
+    ]).then((results) => {
+      results.forEach((result, index) => {
+        if (result.status === "rejected") {
+          console.error(
+            `[createNewCustomer] Operation ${index} failed:`,
+            result.reason
+          );
+        }
+      });
+    }),
   );

apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (1)

235-252: Consider logging failures from Promise.allSettled.

Invoice payment is a critical flow. Silent failures in workflow execution or stats syncing could lead to incorrect partner metrics and missed commissions.

Add error logging:

     waitUntil(
-      Promise.allSettled([
+      Promise.allSettled([
         executeWorkflows({
           trigger: WorkflowTrigger.saleRecorded,
           context: {
             programId: link.programId,
             partnerId: link.partnerId,
             current: {
               saleAmount: saleData.amount,
               conversions: firstConversionFlag ? 1 : 0,
             },
           },
         }),
         syncPartnerLinksStats({
           partnerId: link.partnerId,
           programId: link.programId,
           eventType: "sale",
         }),
-      ]),
+      ]).then((results) => {
+        results.forEach((result, index) => {
+          if (result.status === "rejected") {
+            console.error(
+              `[invoicePaid] Failed to ${index === 0 ? "execute workflows" : "sync partner stats"} for invoice ${invoiceId}:`,
+              result.reason
+            );
+          }
+        });
+      }),
     );

apps/web/lib/api/conversions/track-sale.ts (2)

371-387: Consider logging failures from Promise.allSettled.

In the lead tracking flow, silent failures could result in missed workflow executions or inconsistent partner stats.

Add error logging:

-        await Promise.allSettled([
+        const results = await Promise.allSettled([
           executeWorkflows({
             trigger: WorkflowTrigger.leadRecorded,
             context: {
               programId: link.programId,
               partnerId: link.partnerId,
               current: {
                 leads: 1,
               },
             },
           }),
           syncPartnerLinksStats({
             partnerId: link.partnerId,
             programId: link.programId,
             eventType: "lead",
           }),
         ]);
+
+        results.forEach((result, index) => {
+          if (result.status === "rejected") {
+            console.error(
+              `[trackLead] Failed to ${index === 0 ? "execute workflows" : "sync partner stats"}:`,
+              result.reason
+            );
+          }
+        });

---

551-568: Consider logging failures from Promise.allSettled.

In the sale tracking flow, failures in workflow execution or stats syncing should be logged for debugging and monitoring.

Add error logging:

-        await Promise.allSettled([
+        const results = await Promise.allSettled([
           executeWorkflows({
             trigger: WorkflowTrigger.saleRecorded,
             context: {
               programId: link.programId,
               partnerId: link.partnerId,
               current: {
                 saleAmount: saleData.amount,
                 conversions: firstConversionFlag ? 1 : 0,
               },
             },
           }),
           syncPartnerLinksStats({
             partnerId: link.partnerId,
             programId: link.programId,
             eventType: "sale",
           }),
         ]);
+
+        results.forEach((result, index) => {
+          if (result.status === "rejected") {
+            console.error(
+              `[trackSale] Failed to ${index === 0 ? "execute workflows" : "sync partner stats"}:`,
+              result.reason
+            );
+          }
+        });

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/partners-table.tsx (3)

72-89: LGTM! Field naming updated consistently.

The update from clicks/leads/conversions/sales/saleAmount to totalClicks/totalLeads/totalConversions/totalSales/totalSaleAmount aligns with the backend schema changes and improves clarity.

---

227-259: LGTM! Accessor functions updated correctly.

All column accessors properly reference the new total* field names. The formatting functions (nFormatter, currencyFormatter) are applied appropriately.

---

307-313: netRevenue sorting disabled — verify backend support.

The comment indicates netRevenue sorting will be re-enabled once backend support is available. Ensure there's a tracking issue for this.

Can you verify:

1. Is there a tracking issue for re-enabling netRevenue sorting?
2. What backend change is needed to support this?

apps/web/lib/api/partners/sync-total-commissions.ts (1)

12-49: Consider rate limiting and circuit breaker for the fallback path.

The event-driven approach with fallback is well-designed, but consider these edge cases:

1. Thundering herd: If Redis/event publish is temporarily unavailable, all concurrent commission creation requests will fall back to direct DB aggregation. This could overwhelm the database with identical queries.

2. Event ordering: There's no guarantee that events are processed in order. A commission created at time T1 might be processed after a commission created at T2, causing temporary inconsistencies.

3. Eventual consistency window: The webhook receives locally computed totals, but the actual DB value might differ until the event is processed.

Consider implementing:

• Circuit breaker pattern to fail fast when Redis is down
• Rate limiting on the fallback aggregation path
• Idempotency keys on the event stream to handle duplicates
• Documentation of the eventual consistency model for consumers

apps/web/lib/api/partners/sync-partner-links-stats.ts (1)

5-62: LGTM! Consistent event-driven pattern with graceful fallback.

The implementation follows the same event-first, fallback-to-DB pattern as syncTotalCommissions, which promotes consistency across the codebase. The use of undefined instead of null for missing aggregation values (lines 43-47) allows Prisma to handle the update correctly.

Note: The same concerns raised for syncTotalCommissions regarding thundering herd, circuit breakers, and rate limiting apply here as well.

apps/web/lib/api/partners/get-partners-new.ts (1)

69-70: Document behavior for negative netRevenue. The expression programEnrollment.totalSaleAmount - programEnrollment.totalCommissions can yield negative values (e.g., refunds or clawbacks). Clarify in the API docs whether negative netRevenue is expected or should be clamped to zero.

apps/web/lib/zod/schemas/partners.ts (1)

47-58: Do not rename column IDs: exportPartnerColumns uses clicks, leads, conversions, sales, and saleAmount to match the response object properties returned by getPartners (which maps the DB aliases totalClicks, totalLeads, etc. back to those keys).

Likely an incorrect or invalid review comment.

apps/web/lib/upstash/redis-streams.ts (2)

141-164: LGTM on workspace usage stream refactor.

Making WORKSPACE_USAGE_UPDATES_STREAM_KEY a local constant and updating publishClickEvent to use the object payload pattern with redis.xadd are good improvements. The error handling is consistent and appropriate.

---

166-177: LGTM on partner activity stream infrastructure.

The new partner activity stream infrastructure is well-designed:

• Clear separation of concerns with PARTNER_ACTIVITY_STREAM_KEY constant and partnerActivityStream export
• PartnerActivityEvent interface is properly typed with appropriate event types
• Consistent with the existing workspace usage stream pattern

Reviewing files that changed from the base of the PR and between f66e25a and 2b18a68.

• apps/web/app/(ee)/api/track/click/route.ts (1 hunks)
• apps/web/app/(ee)/api/track/open/route.ts (1 hunks)
• apps/web/lib/middleware/link.ts (7 hunks)
• apps/web/lib/tinybird/record-click.ts (5 hunks)

• GitHub Check: build

apps/web/app/(ee)/api/track/open/route.ts (1)

117-118: Partner/program context propagation looks good

Passing programId/partnerId aligns with recordClick’s optional params and event path.

Confirm RedisLinkProps/formatRedisLink always include programId/partnerId for deep links so events fire when expected.

apps/web/app/(ee)/api/track/click/route.ts (1)

139-141: Correctly threads partner/program into click recording

Matches the new recordClick signature and integrates with existing dedupe/caching.

Reviewing files that changed from the base of the PR and between 2b18a68 and 413c063.

• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/[partnerId]/partner-stats.tsx (1 hunks)
• apps/web/ui/partners/partner-info-stats.tsx (1 hunks)

• GitHub Check: build

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

11-37: LGTM! Field migration is clean and consistent.

The migration from legacy field names (clicks, leads, conversions, saleAmount) to total-prefixed fields (totalClicks, totalLeads, totalConversions, totalSaleAmount) is correctly implemented. The NaN checks and formatting logic remain appropriate, and the null coalescing operator on line 34 provides explicit safety for totalSaleAmount.

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

21-35: Field migration looks good.

The migration from legacy field names (clicks, leads, conversions) to total-prefixed fields (totalClicks, totalLeads, totalConversions) is correctly implemented with appropriate NaN checks and formatting.

Reviewing files that changed from the base of the PR and between 413c063 and 41fe9ea.

• apps/web/scripts/cal/backfill-referral-links.ts (1 hunks)

• GitHub Check: build

Reviewing files that changed from the base of the PR and between 09555e0 and 9d0aaa0.

• apps/web/app/(ee)/api/cron/streams/update-partner-stats/route.ts (1 hunks)
• apps/web/app/(ee)/api/partners/route.ts (1 hunks)
• apps/web/lib/api/partners/get-partner-for-program.ts (1 hunks)
• apps/web/lib/api/partners/get-partners.ts (1 hunks)
• apps/web/scripts/partners/aggregate-stats.ts (1 hunks)
• apps/web/vercel.json (1 hunks)

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

• GitHub Check: build

apps/web/scripts/partners/aggregate-stats.ts (3)

1-3: LGTM!

The imports are appropriate for the script's purpose. Using dotenv-flow/config for side effects is the correct pattern for loading environment variables.

---

158-169: LGTM!

The conversion to array format and the use of console.table for output is appropriate for a PoC/test script. The immediate invocation of main() is the correct pattern for a standalone script.

---

137-137: Earnings field non-nullable with default 0
The Prisma schema defines earnings as a non-nullable Int with @default(0), so null values aren’t possible and earnings: { not: 0 } correctly filters out zero earnings.

Reviewing files that changed from the base of the PR and between 9d0aaa0 and 701e4f7.

• apps/web/app/(ee)/api/cron/streams/update-partner-stats/route.ts (1 hunks)
• apps/web/app/(ee)/api/partners/export/route.ts (1 hunks)

• GitHub Check: build

apps/web/app/(ee)/api/cron/streams/update-partner-stats/route.ts (2)

199-211: LGTM! Error handling and logging are well-structured.

The success rate calculation, progress logging, and limited error reporting (first 5 errors) provide good observability without overwhelming the logs.

---

228-261: LGTM! The endpoint handler is well-structured.

The GET handler properly verifies the request signature, processes the stream batch, handles the no-updates case, and returns a structured response with monitoring information. Error handling is consistent with the codebase standards.

Reviewing files that changed from the base of the PR and between 701e4f7 and 8134579.

• apps/web/app/(ee)/api/bounties/route.ts (1 hunks)
• apps/web/app/(ee)/api/commissions/[commissionId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/discount-codes/route.ts (2 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/analytics/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/bounties/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/customers/[customerId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/count/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/timeseries/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/events/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/route.ts (2 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/resources/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/route.ts (2 hunks)
• apps/web/app/(ee)/api/workflows/partner-approved/route.ts (1 hunks)
• apps/web/app/(ee)/app.dub.co/embed/referrals/utils.ts (4 hunks)
• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/partners-table.tsx (6 hunks)
• apps/web/lib/actions/partners/archive-partner.ts (1 hunks)
• apps/web/lib/actions/partners/ban-partner.ts (2 hunks)
• apps/web/lib/actions/partners/create-bounty-submission.ts (1 hunks)
• apps/web/lib/actions/partners/create-clawback.ts (1 hunks)
• apps/web/lib/actions/partners/create-manual-commission.ts (3 hunks)
• apps/web/lib/actions/partners/create-partner-comment.ts (1 hunks)
• apps/web/lib/actions/partners/deactivate-partner.ts (2 hunks)
• apps/web/lib/actions/partners/mark-program-messages-read.ts (1 hunks)
• apps/web/lib/actions/partners/message-partner.ts (1 hunks)
• apps/web/lib/actions/partners/message-program.ts (1 hunks)
• apps/web/lib/actions/partners/update-partner-enrollment.ts (1 hunks)
• apps/web/lib/actions/partners/upload-bounty-submission-file.ts (1 hunks)
• apps/web/lib/api/partners/backfill-link-commissions.ts (1 hunks)
• apps/web/lib/api/programs/get-program-enrollment-or-throw.ts (3 hunks)
• apps/web/lib/partners/create-partner-commission.ts (3 hunks)
• apps/web/lib/partners/determine-partner-reward.ts (1 hunks)
• apps/web/scripts/migrations/backfill-click-commissions.ts (1 hunks)
• apps/web/scripts/partners/aggregate-stats-seeding.ts (1 hunks)
• apps/web/scripts/tella/update-commissions.ts (1 hunks)
• apps/web/tests/partners/resource.ts (1 hunks)

• GitHub Check: build

apps/web/app/(ee)/api/discount-codes/route.ts (1)

28-30: LGTM! Clean refactoring to explicit include pattern.

The migration from boolean flags (includeDiscountCodes, includeDiscount) to explicit nested include objects improves clarity about which relations are loaded. The destructuring pattern in the POST handler enhances readability while maintaining identical behavior and null safety.

Also applies to: 71-80

apps/web/app/(ee)/app.dub.co/embed/referrals/utils.ts (1)

22-31: LGTM! Include object consolidation improves API consistency.

The refactor from multiple boolean flags to a single include object is cleaner and aligns with the broader refactoring patterns across the PR.

apps/web/scripts/partners/aggregate-stats-seeding.ts (1)

34-45: LGTM!

The result logging is appropriate for a PoC script. The top 10 slice and table format provide a good overview of the aggregated partner statistics.

apps/web/lib/actions/partners/message-program.ts (1)

22-26: LGTM!

The addition of include: {} aligns with the broader refactor to standardize the getProgramEnrollmentOrThrow API. The empty include is appropriate here since the code only needs the enrollment's programId and doesn't require any related data.

apps/web/lib/actions/partners/mark-program-messages-read.ts (1)

19-23: LGTM!

The addition of include: {} is consistent with the PR's refactoring pattern. The empty include is appropriate since only partnerId and programId are destructured and used.

apps/web/lib/actions/partners/upload-bounty-submission-file.ts (1)

36-41: LGTM!

The addition of include: {} aligns with the standardized include pattern. The empty include is correct since the code only accesses the enrollment's own fields (status, groupId) without needing related entities.

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

37-45: LGTM!

The migration from includeProgram: true to include: { program: true } correctly transitions to the standardized include object pattern. The included program data is necessary for accessing programEnrollment.program.defaultGroupId on line 63.

apps/web/lib/actions/partners/archive-partner.ts (1)

20-24: LGTM!

The addition of include: {} is consistent with the refactoring pattern. The empty include is appropriate since only the status field from the enrollment itself is accessed.

apps/web/lib/actions/partners/create-partner-comment.ts (1)

21-25: LGTM!

The addition of include: {} follows the standardized pattern. The empty include is appropriate since the call is only validating that the enrollment exists (no data from the result is used).

apps/web/app/(ee)/api/workflows/partner-approved/route.ts (1)

56-65: LGTM!

The migration to include: { program: true, partner: true, links: true } correctly transitions to the standardized include object pattern. The included data is necessary for the destructuring on line 56 and subsequent usage throughout the workflow steps.

apps/web/lib/actions/partners/create-manual-commission.ts (2)

71-79: LGTM!

The migration to include: { partner: true, links: true } correctly transitions to the standardized include object pattern. The included partner and links data are necessary for the destructuring on line 71 and subsequent usage throughout the function.

---

523-546: LGTM! Good parallelization pattern.

The use of Promise.allSettled to run executeWorkflows and syncPartnerLinksStats in parallel is a good practice that improves performance. The type assertion commissionType as "lead" | "sale" on line 543 is safe because it's guarded by the conditional check on line 523 that filters to only these two values.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/count/route.ts (1)

16-18: LGTM! Consistent refactoring to structured include.

The migration from implicit includes to an explicit include: { program: true } makes the data requirements clear at the call site without changing any logic.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/bounties/route.ts (1)

15-18: LGTM! Explicit includes for program and links.

The structured include ensures that both program and links are fetched alongside the enrollment, supporting downstream usage in bounty filtering (line 26) and aggregation (line 83).

apps/web/app/(ee)/api/partner-profile/programs/[programId]/events/route.ts (1)

26-28: LGTM! Clear data requirements.

The explicit include: { program: true } ensures program data is available for event filtering (lines 54, 56) without side effects.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/customers/[customerId]/route.ts (1)

18-21: LGTM! Necessary includes for customer retrieval.

Both program and links are required downstream: program for validation (line 30) and links for event filtering (line 39). The structured include makes this explicit.

apps/web/lib/api/partners/backfill-link-commissions.ts (1)

29-33: LGTM! Migration to structured include.

Replaces the includeSaleReward boolean flag with an explicit include object. All three relations (program, links, saleReward) are used downstream for determining rewards and creating commissions.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/route.ts (1)

19-21: LGTM! Explicit program include.

The structured include ensures program data is available for the earnings query (line 50) without altering control flow.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1)

24-37: LGTM! Structured include with clear aliasing.

The migration from includeGroup: true to include: { program: true, links: true, partnerGroup: true } improves clarity, and the destructuring alias partnerGroup: group maintains readable variable names for downstream validation (lines 46, 82, 86).

apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/timeseries/route.ts (1)

17-20: LGTM! Explicit includes for timeseries.

Both program and links are required: program for date boundaries (line 40) and query filtering (line 59), and links for groupBy aggregation (line 109). The structured include makes these dependencies explicit.

apps/web/tests/partners/resource.ts (1)

30-30: Approve bannedAt field addition
The bannedAt field is defined in program.prisma, mirrored in Zod schemas (programs.ts), and handled in all partner actions—tests align with production code.

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/partners-table.tsx (3)

65-91: LGTM! Column definitions consistently updated.

The column definitions have been updated consistently to use total* prefixed fields, aligning with the data model changes. The netRevenue field appropriately remains without the total prefix as it appears to be a calculated metric.

---

146-146: LGTM! Column visibility key versioning.

The version bump in the column visibility key prevents issues with stale user preferences that reference the old column names. This is the correct approach for a breaking schema change.

---

306-315: LGTM! Sortable columns updated with temporary netRevenue limitation noted.

The sortable columns have been correctly updated to use the total* prefixed fields. The comment on line 314 clearly indicates that netRevenue sorting is temporarily disabled and will be re-enabled when backend support is available.

apps/web/lib/partners/determine-partner-reward.ts (1)

16-22: Verify getProgramEnrollmentOrThrow selects links Confirm that the getProgramEnrollmentOrThrow query includes the links relation so every programEnrollment passed into determinePartnerReward satisfies the now-required links field.

Reviewing files that changed from the base of the PR and between 8134579 and 31e6fb2.

• apps/web/lib/api/programs/get-program-enrollment-or-throw.ts (3 hunks)
• apps/web/scripts/partners/aggregate-stats-seeding.ts (1 hunks)

• GitHub Check: build

apps/web/lib/api/programs/get-program-enrollment-or-throw.ts (1)

57-62: LGTM! Slug lookup issue resolved.

The error check now only verifies programEnrollment presence, which correctly handles slug-based lookups without requiring the program relation to be included. This fixes the 404 issue from the previous review.

apps/web/scripts/partners/aggregate-stats-seeding.ts (2)

1-3: LGTM!

The imports are appropriate for this seeding script.

---

6-45: LGTM!

The query logic correctly aggregates partner activity metrics and the logging provides useful visibility into the top performers.

Reviewing files that changed from the base of the PR and between eaec736 and 31e6fb2.

• apps/web/app/(ee)/api/bounties/route.ts (1 hunks)
• apps/web/app/(ee)/api/commissions/[commissionId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/cron/aggregate-clicks/route.ts (1 hunks)
• apps/web/app/(ee)/api/cron/streams/update-partner-stats/route.ts (1 hunks)
• apps/web/app/(ee)/api/discount-codes/route.ts (2 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/analytics/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/bounties/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/customers/[customerId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/count/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/timeseries/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/events/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/route.ts (2 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/resources/route.ts (1 hunks)
• apps/web/app/(ee)/api/partner-profile/programs/[programId]/route.ts (2 hunks)
• apps/web/app/(ee)/api/partners/export/route.ts (1 hunks)
• apps/web/app/(ee)/api/partners/route.ts (1 hunks)
• apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (2 hunks)
• apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (2 hunks)
• apps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts (2 hunks)
• apps/web/app/(ee)/api/track/click/route.ts (1 hunks)
• apps/web/app/(ee)/api/track/open/route.ts (1 hunks)
• apps/web/app/(ee)/api/workflows/partner-approved/route.ts (1 hunks)
• apps/web/app/(ee)/app.dub.co/embed/referrals/utils.ts (4 hunks)
• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/[partnerId]/partner-stats.tsx (1 hunks)
• apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/partners-table.tsx (6 hunks)
• apps/web/lib/actions/partners/archive-partner.ts (1 hunks)
• apps/web/lib/actions/partners/ban-partner.ts (2 hunks)
• apps/web/lib/actions/partners/create-bounty-submission.ts (1 hunks)
• apps/web/lib/actions/partners/create-clawback.ts (1 hunks)
• apps/web/lib/actions/partners/create-manual-commission.ts (3 hunks)
• apps/web/lib/actions/partners/create-partner-comment.ts (1 hunks)
• apps/web/lib/actions/partners/deactivate-partner.ts (2 hunks)
• apps/web/lib/actions/partners/mark-program-messages-read.ts (1 hunks)
• apps/web/lib/actions/partners/message-partner.ts (1 hunks)
• apps/web/lib/actions/partners/message-program.ts (1 hunks)
• apps/web/lib/actions/partners/update-partner-enrollment.ts (1 hunks)
• apps/web/lib/actions/partners/upload-bounty-submission-file.ts (1 hunks)
• apps/web/lib/api/conversions/track-lead.ts (2 hunks)
• apps/web/lib/api/conversions/track-sale.ts (3 hunks)
• apps/web/lib/api/partners/backfill-link-commissions.ts (1 hunks)
• apps/web/lib/api/partners/get-partner-for-program.ts (1 hunks)
• apps/web/lib/api/partners/get-partners.ts (1 hunks)
• apps/web/lib/api/partners/sync-partner-links-stats.ts (1 hunks)
• apps/web/lib/api/partners/sync-total-commissions.ts (2 hunks)
• apps/web/lib/api/programs/get-program-enrollment-or-throw.ts (3 hunks)
• apps/web/lib/firstpromoter/import-commissions.ts (2 hunks)
• apps/web/lib/firstpromoter/import-customers.ts (4 hunks)
• apps/web/lib/integrations/shopify/create-sale.ts (2 hunks)
• apps/web/lib/middleware/link.ts (7 hunks)
• apps/web/lib/partners/create-partner-commission.ts (3 hunks)
• apps/web/lib/partners/determine-partner-reward.ts (1 hunks)
• apps/web/lib/partnerstack/import-commissions.ts (2 hunks)
• apps/web/lib/partnerstack/import-customers.ts (4 hunks)
• apps/web/lib/rewardful/import-commissions.ts (2 hunks)
• apps/web/lib/rewardful/import-customers.ts (3 hunks)
• apps/web/lib/tinybird/record-click.ts (5 hunks)
• apps/web/lib/tolt/import-commissions.ts (2 hunks)
• apps/web/lib/tolt/import-customers.ts (5 hunks)
• apps/web/lib/upstash/redis-streams.ts (1 hunks)
• apps/web/lib/zod/schemas/partners.ts (2 hunks)
• apps/web/scripts/cal/backfill-referral-links.ts (1 hunks)
• apps/web/scripts/migrations/backfill-click-commissions.ts (1 hunks)
• apps/web/scripts/partners/aggregate-stats-seeding.ts (1 hunks)
• apps/web/scripts/partners/aggregate-stats.ts (1 hunks)
• apps/web/scripts/tella/update-commissions.ts (1 hunks)
• apps/web/tests/partners/resource.ts (1 hunks)
• apps/web/ui/links/link-builder/link-partner-details.tsx (1 hunks)
• apps/web/ui/partners/partner-info-stats.tsx (1 hunks)
• apps/web/vercel.json (1 hunks)
• packages/prisma/schema/program.prisma (1 hunks)

apps/web/lib/actions/partners/create-clawback.ts (1)

17-21: LGTM! API consistency change with no functional impact.

The include: {} parameter has no effect here since the result of getProgramEnrollmentOrThrow is unused—the call is purely for validation (it throws if the enrollment doesn't exist). However, adding this parameter maintains API consistency across the codebase as part of the broader refactor to standardize include patterns.

apps/web/ui/links/link-builder/link-partner-details.tsx (1)

59-61: LGTM! Field rename aligns with the data model refactoring.

The change from saleAmount to totalSaleAmount is consistent with the broader refactoring to use total-prefixed fields for aggregate partner metrics. The logic and currency formatting remain correct.

apps/web/tests/partners/resource.ts (1)

30-30: LGTM. bannedAt matches existing nullable date-field patterns; ensure your database model (e.g. Prisma schema and migrations) includes a corresponding bannedAt column.

apps/web/app/(ee)/api/discount-codes/route.ts (2)

28-30: LGTM! Include pattern standardization.

The refactor from includeDiscountCodes: true to include: { discountCodes: true } aligns with the PR's goal of standardizing data fetching across the codebase. The explicit include pattern improves clarity.

---

71-80: LGTM! Improved readability with explicit includes.

The changes correctly standardize the include pattern and add destructuring for cleaner code:

• Explicitly includes all required relationships: links, discount, and discountCodes
• Destructuring { links, discount } reduces verbosity in subsequent code
• All included relationships are used in the handler logic

The explicit include pattern is a good practice as it makes data dependencies clear at the fetch site.

apps/web/scripts/cal/backfill-referral-links.ts (1)

91-93: Confirm createAndEnrollPartner returns totalClicks/totalLeads/totalSales. The mapping at lines 91–93 depends on these properties but they’re not present in the current implementation or TS definition—ensure the API response and return type have been updated accordingly.

apps/web/app/(ee)/app.dub.co/embed/referrals/utils.ts (1)

95-100: Avoid unsafe as PartnerGroupProps cast. It bypasses TS checks—ensure you map all fields from PartnerGroup & { additionalLinks: … } or use satisfies PartnerGroupProps so missing or mismatched props are caught.

apps/web/lib/middleware/link.ts (1)

282-283: LGTM!

The addition of programId and partnerId to all recordClick calls is consistent across all redirect paths and correctly references cachedLink properties. This enables partner activity tracking as intended by the PR.

Also applies to: 335-336, 375-376, 417-418, 488-489, 524-525, 560-561

apps/web/lib/actions/partners/message-program.ts (1)

22-26: LGTM!

The addition of include: {} correctly adapts to the new function signature. Since only programId is used from the enrollment result, an empty include is appropriate.

apps/web/lib/actions/partners/message-partner.ts (1)

39-43: LGTM!

The addition of include: {} correctly adapts to the new function signature. Since the function only validates enrollment existence, an empty include is appropriate.

apps/web/lib/actions/partners/mark-program-messages-read.ts (1)

19-23: LGTM!

The addition of include: {} correctly adapts to the new function signature. Since only partnerId and programId are used from the result, an empty include is appropriate.

apps/web/lib/actions/partners/upload-bounty-submission-file.ts (1)

36-41: LGTM!

The addition of include: {} correctly adapts to the new function signature. Since only scalar fields (status, groupId) are used from the enrollment result, an empty include is appropriate.

apps/web/scripts/migrations/backfill-click-commissions.ts (1)

12-19: LGTM!

The migration from includeClickReward: true to include: { links: true, clickReward: true } correctly adapts to the new function signature. The included relations are appropriately used in the script (line 21 for reward determination and line 26 for link lookup).

apps/web/vercel.json (2)

16-17: LGTM!

The path rename from /api/cron/usage/update-workspace-clicks to /api/cron/streams/update-workspace-clicks aligns with the PR's shift to streams-based architecture for partner activity processing.

---

19-22: LGTM!

The new partner-stats cron running every 5 minutes (*/5 * * * *) appropriately supports the PR's goal of syncing partner link statistics to the ProgramEnrollment table. The frequency balances timely updates with system load.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/links/[linkId]/route.ts (1)

24-37: LGTM! Clean refactoring to structured include pattern.

The change from a boolean includeGroup flag to a structured include object improves clarity and aligns with the standardized pattern used across the codebase. The destructuring of partnerGroup to group maintains backward compatibility with downstream usage.

apps/web/app/(ee)/api/track/open/route.ts (1)

117-118: LGTM! Enhanced click tracking with program context.

Adding programId and partnerId from the cached link provides necessary context for downstream partner activity tracking and stats synchronization. This aligns with the broader partner link statistics infrastructure being introduced.

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

4-52: LGTM! Clean migration to total-prefixed stats fields.

The updates consistently migrate from the original field names (clicks, leads, conversions, saleAmount) to the new total* prefixed fields, while adding support for totalCommissions and netRevenue. The formatting logic and NaN handling remain unchanged.

apps/web/lib/partners/determine-partner-reward.ts (1)

16-22: Verify callers include required links field

The links property on ProgramEnrollmentWithReward is now required (links: Link[] | null). Ensure every call to determinePartnerReward (e.g. in apps/web/scripts/*, create-partner-commission.ts, API routes under apps/web/lib/api, and app routes under apps/web/app) explicitly passes a links field—even if null.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/route.ts (1)

10-22: LGTM!

The migration to the unified include object pattern is consistent with the broader PR changes and correctly includes all necessary related data (program, partner, links, rewards, partnerGroup).

apps/web/app/(ee)/api/cron/streams/update-partner-stats/route.ts (1)

172-181: LGTM! SQL injection risk properly mitigated.

The UPDATE statement is now correctly parameterized with SET before WHERE, and all values are passed as bound parameters. This addresses the SQL injection and syntax issues flagged in previous reviews.

apps/web/lib/tinybird/record-click.ts (1)

217-230: LGTM! Partner activity event publishing with robust fallback.

The implementation correctly publishes partner activity events with a database fallback if the stream publish fails. The pattern is consistent with the workspace usage increment above, and the parameterized SQL prevents injection risks.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/analytics/route.ts (1)

11-18: LGTM!

The migration to include: { program: true, links: true } is consistent with the broader PR pattern and correctly provides the necessary data for downstream analytics processing.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/resources/route.ts (1)

8-14: LGTM!

The addition of include: { program: true } is appropriate for this endpoint and aligns with the broader PR pattern of using unified include objects.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/bounties/route.ts (1)

11-19: LGTM!

The migration to include: { program: true, links: true } correctly provides the necessary data for bounty processing and partner stats aggregation.

apps/web/lib/actions/partners/update-partner-enrollment.ts (1)

31-33: LGTM! Clean refactor to generalized include pattern.

The change from includePartner: true to include: { partner: true } aligns with the broader refactoring effort across the codebase. This pattern provides better flexibility for including multiple relations without proliferating boolean flags.

apps/web/lib/tolt/import-commissions.ts (1)

380-384: LGTM! Partner stats sync integrated consistently.

The syncPartnerLinksStats call is appropriately added in parallel with other commission-related operations. This ensures partner enrollment statistics stay synchronized with sale events during the import flow.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/timeseries/route.ts (1)

17-20: LGTM! Enriches enrollment data for downstream use.

The include object fetches program and links data, which are used later in the handler for query construction and response formatting (lines 40, 109-112).

apps/web/app/(ee)/api/partner-profile/programs/[programId]/customers/[customerId]/route.ts (1)

18-21: LGTM! Include pattern supports downstream operations.

The program and links data are appropriately used later in the handler (lines 30, 39) for validation and event retrieval.

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

373-377: LGTM! Consistent partner stats synchronization.

The syncPartnerLinksStats call follows the same pattern as the Tolt imports, ensuring partner enrollment metrics remain in sync during commission imports.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/events/route.ts (1)

26-28: LGTM! Program data correctly included.

The program object is used downstream for event retrieval (lines 54, 56), making this include necessary and appropriate.

apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/count/route.ts (1)

16-18: LGTM! Program inclusion supports query construction.

The program data is used for building the earnings count query (line 42), making this a logical addition.

apps/web/lib/api/partners/backfill-link-commissions.ts (1)

29-33: LGTM! Refactor to comprehensive include pattern.

The migration from includeSaleReward: true to a structured include object that fetches program, links, and saleReward aligns with the codebase-wide refactoring. All included data is utilized downstream (lines 36-41).

apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/route.ts (1)

19-21: LGTM! Consistent refactor pattern.

The change from a boolean flag to a structured include object aligns with the broader refactoring effort across the codebase. The program object is properly destructured and used downstream.

apps/web/lib/actions/partners/archive-partner.ts (1)

23-23: LGTM! Appropriate use of empty include.

The empty include object is correct here since only the programEnrollment status is needed for the archive operation, with no related entities required.

apps/web/app/(ee)/api/workflows/partner-approved/route.ts (1)

60-64: LGTM! Properly structured include object.

The include object correctly fetches program, partner, and links, which are all used throughout the workflow steps (default link creation, email notification, webhook payload).

apps/web/app/(ee)/api/track/click/route.ts (1)

139-140: LGTM! Proper context propagation.

Adding programId and partnerId to the click event correctly propagates partner/program context for downstream partner activity tracking and statistics synchronization.

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

41-43: LGTM! Consistent refactor pattern.

The structured include object is used correctly to fetch the program relation, which is accessed later for filtering bounties by group (lines 62-63).

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

366-370: LGTM! Correct stats synchronization.

The syncPartnerLinksStats call with eventType: "sale" is correct for the PartnerStack commission import flow and properly parallelized with other stat updates.

apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (1)

456-460: LGTM! Correct stats synchronization.

The syncPartnerLinksStats call with eventType: "sale" is correct for the Stripe checkout completion webhook and properly parallelized with workflow execution.

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

244-278: LGTM! Proper error tolerance and conditional stats sync.

The migration to Promise.allSettled ensures that a failure in one operation (recording lead, updating link stats, or syncing partner stats) doesn't block the others. The type guard for partnerId and programId correctly handles the case where partner links may not have these fields.

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

65-90: LGTM! Consistent migration to total-prefixed fields.

The column definitions, accessors, and default sort configuration have been updated consistently from legacy fields to total* prefixed fields. The column visibility key change to "partners-table-columns-v2" ensures a clean migration for existing users.

Note: A previous review comment flagged that EnrolledPartnerProps may need updating to include these fields. Ensure the type definition in apps/web/lib/zod/schemas/partners.ts includes all total* fields to prevent runtime errors.

---

306-315: Confirm backend support for netRevenue sorting
No netRevenue field exists in the Prisma schema—ensure the API computes and exposes sortable netRevenue before uncommenting it.

apps/web/lib/api/partners/sync-partner-links-stats.ts (1)

42-48: Verify undefined fallback for null aggregates.

The aggregate mapping uses ?? undefined instead of ?? 0. If all links for a partner are deleted or have null stats, the update operation will not reset these fields to zero, potentially leaving stale data.

Confirm this is intentional behavior. If stats should be zeroed when no data exists, use ?? 0:

       const partnerLinkStats = {
-        totalClicks: res._sum.clicks ?? undefined,
-        totalLeads: res._sum.leads ?? undefined,
-        totalConversions: res._sum.conversions ?? undefined,
-        totalSales: res._sum.sales ?? undefined,
-        totalSaleAmount: res._sum.saleAmount ?? undefined,
+        totalClicks: res._sum.clicks ?? 0,
+        totalLeads: res._sum.leads ?? 0,
+        totalConversions: res._sum.conversions ?? 0,
+        totalSales: res._sum.sales ?? 0,
+        totalSaleAmount: res._sum.saleAmount ?? 0,
       };

apps/web/lib/actions/partners/ban-partner.ts (1)

29-38: LGTM! Consolidates data fetching with include object.

The migration to the unified include object pattern removes the need for a separate Prisma query to fetch links. This simplifies the code and ensures all related data is loaded in a single query.

apps/web/lib/api/partners/get-partners.ts (1)

63-71: LGTM! Clean data mapping with computed netRevenue.

The response mapping correctly spreads partner and programEnrollment data, preserves the links relation, and computes netRevenue from the aggregated stats. The id and createdAt field assignments ensure consistency with the expected return type.

apps/web/lib/zod/schemas/partners.ts (1)

374-416: LGTM! Schema correctly defines total-prefixed stats fields.

The EnrolledPartnerSchema correctly defines all total* fields with appropriate defaults and descriptions. This resolves the concern raised in a previous review about missing type definitions for the partners table.

Reviewing files that changed from the base of the PR and between 5affef5 and 1000d47.

• apps/web/lib/api/groups/get-groups.ts (1 hunks)
• apps/web/lib/api/partners/get-partners.ts (2 hunks)
• apps/web/ui/partners/groups/group-selector.tsx (2 hunks)