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.