Reviewing files that changed from the base of the PR and between eb2c48c and df14e86.

• packages/prisma/schema/link.prisma (2 hunks)

Reviewing files that changed from the base of the PR and between ece5240 and f4e95dd.

• 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.ts (2 hunks)
• apps/web/lib/actions/partners/create-manual-commission.ts (2 hunks)
• apps/web/lib/api/conversions/track-lead.ts (1 hunks)
• apps/web/lib/api/conversions/track-sale.ts (3 hunks)
• apps/web/lib/api/links/update-link-stats-for-importer.ts (1 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-lead.ts (2 hunks)
• apps/web/lib/integrations/shopify/create-sale.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 (2 hunks)
• apps/web/lib/tolt/import-commissions.ts (2 hunks)
• apps/web/lib/tolt/import-customers.ts (4 hunks)

• apps/web/lib/api/conversions/track-lead.ts
• apps/web/lib/integrations/shopify/create-lead.ts

• GitHub Check: build

apps/web/app/(ee)/api/stripe/integration/webhook/utils.ts (1)

78-88: lastLeadAt update looks good

Incrementing the lead count while stamping lastLeadAt with the current time keeps the link stats in sync with the new column. No issues spotted.

Reviewing files that changed from the base of the PR and between eb2c48c and f93e714.

• 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.ts (2 hunks)
• apps/web/lib/actions/partners/create-manual-commission.ts (7 hunks)
• apps/web/lib/api/conversions/track-lead.ts (1 hunks)
• apps/web/lib/api/conversions/track-sale.ts (3 hunks)
• apps/web/lib/api/links/update-link-stats-for-importer.ts (1 hunks)
• apps/web/lib/api/links/utils/transform-link.ts (1 hunks)
• apps/web/lib/firstpromoter/import-commissions.ts (2 hunks)
• apps/web/lib/firstpromoter/import-customers.ts (6 hunks)
• apps/web/lib/integrations/shopify/create-lead.ts (2 hunks)
• apps/web/lib/integrations/shopify/create-sale.ts (1 hunks)
• apps/web/lib/partnerstack/import-commissions.ts (2 hunks)
• apps/web/lib/partnerstack/import-customers.ts (6 hunks)
• apps/web/lib/rewardful/import-commissions.ts (2 hunks)
• apps/web/lib/rewardful/import-customers.ts (2 hunks)
• apps/web/lib/tolt/import-commissions.ts (2 hunks)
• apps/web/lib/tolt/import-customers.ts (5 hunks)
• packages/prisma/schema/link.prisma (2 hunks)

apps/web/lib/api/links/utils/transform-link.ts (1)

31-41: Hiding internal timestamps from API response — LGTM

Stripping disabledAt, lastLeadAt, and lastConversionAt here is appropriate and consistent with prior redactions.

packages/prisma/schema/link.prisma (2)

65-66: Migration gap applies to lastLeadAt/lastConversionAt as well

Ensure the same migration includes these fields.

Use the script above; expect to see ALTER TABLE statements adding all three columns in a single migration. If missing, generate one (e.g., pnpm prisma migrate dev --name add-link-timestamps) and commit.

---

10-10: Blocking: add and commit the Prisma migration for new columns

disabledAt requires a migration. Without it, deploys will fail and columns won’t exist.

Run to verify whether a migration exists in this PR:

#!/bin/bash
set -euo pipefail

echo "Searching for migrations mentioning Link/disabledAt/lastLeadAt/lastConversionAt..."
fd -t d migrations packages/prisma | wc -l

rg -n -C2 -i 'disabledAt|lastLeadAt|lastConversionAt' packages/prisma/migrations || true

echo "Prisma schema snapshot:"
sed -n '1,140p' packages/prisma/schema/link.prisma | sed -n '1,120p'

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

140-143: Good: preserving real event timestamps for link stats

Capturing leadEventTimestamp/saleEventTimestamp from the actual events fixes the earlier “use now()” issue in manual/backfill flows.

Also applies to: 230-231, 289-295, 389-391, 431-433

apps/web/lib/api/links/update-link-stats-for-importer.ts (1)

1-20: Avoid regressing timestamps under concurrency; enforce “only move forward” at DB level

This helper bases decisions on a stale in-memory currentTimestamp and can overwrite a newer DB value during concurrent updates. Guard the update in the database (updateMany with a where clause) instead of returning a value to blindly set. Apply the same pattern at call sites.

Proposed addition (keep this function for now, but prefer using these DB-guarded helpers going forward):

// New helpers (exported)
import type { Prisma } from "@dub/prisma";

// Use a transaction client when possible
export async function setLastLeadAtIfNewer(
  tx: Prisma.TransactionClient,
  linkId: string,
  ts: Date,
) {
  return tx.link.updateMany({
    where: { id: linkId, OR: [{ lastLeadAt: null }, { lastLeadAt: { lt: ts } }] },
    data: { lastLeadAt: ts },
  });
}

export async function setLastConversionAtIfNewer(
  tx: Prisma.TransactionClient,
  linkId: string,
  ts: Date,
) {
  return tx.link.updateMany({
    where: {
      id: linkId,
      OR: [{ lastConversionAt: null }, { lastConversionAt: { lt: ts } }],
    },
    data: { lastConversionAt: ts },
  });
}

Then, at call sites, drop lastXAt from prisma.link.update data and invoke one of the helpers in the same Promise.all or transaction.

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

351-355: Guard lastConversionAt update in DB to prevent timestamp regression

This still risks overwriting a newer value under concurrency. Move the update to an updateMany guarded by “NULL or older”.

-          lastConversionAt: updateLinkStatsForImporter({
-            currentTimestamp: customer.link.lastConversionAt,
-            newTimestamp: new Date(commission.created_at),
-          }),

Add a DB-guarded update alongside the existing Promise.all:

   await Promise.all([
     prisma.commission.create({ /* ... */ }),
     recordSaleWithTimestamp({ /* ... */ }),
     // update link stats
     prisma.link.update({ /* ... conversions/sales/saleAmount ... */ }),
+    // ensure lastConversionAt only moves forward
+    isFirstConversion({ customer, linkId: customer.linkId }) &&
+      prisma.link.updateMany({
+        where: {
+          id: customer.linkId,
+          OR: [
+            { lastConversionAt: null },
+            { lastConversionAt: { lt: new Date(commission.created_at) } },
+          ],
+        },
+        data: { lastConversionAt: new Date(commission.created_at) },
+      }),
     // update customer stats
     prisma.customer.update({ /* ... */ }),
   ]);

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

358-361: Same DB-level guard needed for lastConversionAt

Prevent regressions by updating only when NULL/older via updateMany.

-          lastConversionAt: updateLinkStatsForImporter({
-            currentTimestamp: customer.link.lastConversionAt,
-            newTimestamp: new Date(commission.created_at),
-          }),

Add a guarded update alongside the existing Promise.allSettled:

   await Promise.allSettled([
     prisma.commission.create({ /* ... */ }),
     recordSaleWithTimestamp({ /* ... */ }),
     prisma.link.update({ /* conversions/sales/saleAmount ... */ }),
+    (isFirstConversion({ customer, linkId: customer.linkId }) &&
+      prisma.link.updateMany({
+        where: {
+          id: customer.linkId,
+          OR: [
+            { lastConversionAt: null },
+            { lastConversionAt: { lt: new Date(commission.created_at) } },
+          ],
+        },
+        data: { lastConversionAt: new Date(commission.created_at) },
+      })) as any,
     prisma.customer.update({ /* ... */ }),
   ]);

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

352-366: lastConversionAt can still move backwards under concurrent commission imports

Multiple commissions for the same link run this Promise.all in parallel. Each call still reads customerFound.link.lastConversionAt, the helper returns a plain Date, and whichever promise settles last overwrites the column—even if its commission.created_at is older. We need to move the freshness check into the database so concurrent runs can’t regress the timestamp (same issue previously highlighted). Compute the new value once, update counters separately, and use an updateMany with a guard on lastConversionAt.

-  await Promise.all([
+  const shouldCountConversion = isFirstConversion({
+    customer: customerFound,
+    linkId: customerFound.linkId,
+  });
+  const nextLastConversionAt = shouldCountConversion
+    ? updateLinkStatsForImporter({
+        currentTimestamp: customerFound.link.lastConversionAt,
+        newTimestamp: new Date(commission.created_at),
+      })
+    : undefined;
+
+  await Promise.all([
@@
-    prisma.link.update({
-      where: { id: customerFound.linkId },
-      data: {
-        ...(isFirstConversion({
-          customer: customerFound,
-          linkId: customerFound.linkId,
-        }) && {
-          conversions: {
-            increment: 1,
-          },
-          lastConversionAt: updateLinkStatsForImporter({
-            currentTimestamp: customerFound.link.lastConversionAt,
-            newTimestamp: new Date(commission.created_at),
-          }),
-        }),
-        sales: { increment: 1 },
-        saleAmount: { increment: amount },
-      },
-    }),
+    prisma.link.update({
+      where: { id: customerFound.linkId },
+      data: {
+        ...(shouldCountConversion && {
+          conversions: {
+            increment: 1,
+          },
+        }),
+        sales: { increment: 1 },
+        saleAmount: { increment: amount },
+      },
+    }),
+    nextLastConversionAt
+      ? prisma.link.updateMany({
+          where: {
+            id: customerFound.linkId,
+            OR: [
+              { lastConversionAt: null },
+              { lastConversionAt: { lt: nextLastConversionAt } },
+            ],
+          },
+          data: {
+            lastConversionAt: nextLastConversionAt,
+          },
+        })
+      : Promise.resolve(),

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

222-231: Still need a DB-side guard to keep lastLeadAt monotonic

Promise.all means multiple referrals hitting the same link run this block concurrently. Each invocation captures the same stale link.lastLeadAt, the helper returns a plain Date, and whichever promise resolves last wins. That means an older became_lead_at can overwrite a newer timestamp. We have the same race the earlier review flagged—only moving the comparison into userland didn’t fix it. Please push the “is this fresher?” check into the database (e.g. unconditional update for the counters plus a conditional updateMany for the timestamp) so concurrent imports can’t regress lastLeadAt.

-  await Promise.all([
-    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),
-        }),
-      },
-    }),
-  ]);
+  const nextLastLeadAt = updateLinkStatsForImporter({
+    currentTimestamp: link.lastLeadAt,
+    newTimestamp: new Date(referral.became_lead_at),
+  });
+
+  await Promise.all([
+    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 },
+      },
+    }),
+    nextLastLeadAt
+      ? prisma.link.updateMany({
+          where: {
+            id: link.id,
+            OR: [
+              { lastLeadAt: null },
+              { lastLeadAt: { lt: nextLastLeadAt } },
+            ],
+          },
+          data: { lastLeadAt: nextLastLeadAt },
+        })
+      : Promise.resolve(),
+  ]);

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

274-286: Guard lastLeadAt against concurrent downgrades

We still have the same race here: every customer update reads the original link.lastLeadAt, so the slowest task can overwrite a newer value. Match the conditional-write pattern (compute once, then conditional updateMany) used in other importers to ensure we only persist strictly newer timestamps.

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

278-282: Protect lastLeadAt from regressing under concurrency

This block still writes back whatever the stale snapshot said was “current,” so an older customer processed later can clobber a newer timestamp. Apply the same compute-and-conditional-update approach we’ve been standardizing on to keep lastLeadAt monotonic.

apps/web/lib/api/conversions/track-lead.ts (1)

281-286: Lead recency capture looks good.

Setting lastLeadAt alongside the existing lead counter preserves freshness for real-time leads.

apps/web/app/(ee)/api/stripe/integration/webhook/utils.ts (1)

78-88: Stripe-created lead now updates recency correctly.

The timestamp pairs nicely with the counter increment, so this path will surface when the most recent lead arrived.

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

70-82: Shopify lead path keeps recency in sync.

Updating lastLeadAt whenever a lead is recorded ensures the link’s fresh-lead metadata stays accurate.