apps/web/lib/zod/schemas/leads.ts (3)

9-12: Document fallback behavior for optional clickId

Since clickId is now optional and the API falls back to an existing customer’s clickId (see track-lead.ts), update the description to state this behavior and the error thrown when neither is available.

---

16-20: Align eventName normalization with server logic

Server normalizes with toLowerCase().replaceAll(" ", "-") for dedupe keys. Consider adding a schema transform or validation pattern to avoid mismatches (e.g., multiple spaces, non-ASCII).

---

59-63: Clarify deferred mode semantics in schema description

Explain that deferred creates/updates the customer but defers lead ingestion; also mention how the later linkage occurs (e.g., via Redis lead cache used by /track/sale). This reduces ambiguity for integrators.

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

228-235: Use strict equality

Prefer === for mode checks.

-        if (mode == "async" || mode == "deferred") {
+        if (mode === "async" || mode === "deferred") {

---

63-63: Normalize eventName robustly

toLowerCase().replaceAll(" ", "-") is brittle for multiple/Unicode whitespace. Consider a shared slug util to avoid duped keys that differ only by spacing.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

194-195: Remove PII-bearing console logs (reintroduced)

customer JSON and lead recording responses can include PII. These logs were flagged and removed earlier; they should not be present.

Apply:

-      console.log(`customer created: ${JSON.stringify(customer, null, 2)}`);
@@
-          const res = await recordLead(createLeadEventPayload(customer.id));
-          console.log("lead event recorded:", res);
+          await recordLead(createLeadEventPayload(customer.id));

Also applies to: 229-230

---

261-288: Keep per-customer stats consistent: increment customer.leads

Link and workspace usage are updated, but the customer’s leads count isn’t. Update it atomically.

Apply:

-          const [link, _project] = await Promise.all([
+          const [link, _project, _customer] = await Promise.all([
             // update link leads count
             prisma.link.update({
@@
             }),
 
             // update workspace events usage
             prisma.project.update({
@@
             }),
+            // update customer leads count
+            prisma.customer.update({
+              where: { id: customer!.id },
+              data: {
+                leads: { increment: eventQuantity ?? 1 },
+              },
+            }),
           ]);

apps/web/tests/tracks/track-lead.test.ts (1)

158-179: Consider asserting the effect of eventQuantity

Nice scenario. Add an assertion that the side-effect reflects quantity (e.g., link.leads or workspace usage increased by 2) to catch regressions.

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

143-144: Nit: error code semantics

Using not_found for “link does not belong to workspace” avoids info leakage; if you prefer explicit semantics, consider forbidden. Not blocking.

---

123-123: Nit: typo in comment

“from the from the” → “from the”.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

68-85: Fix deferred-mode dedupe: priming call blocks the actual event

Using the same SET NX key for “deferred” and the real event means the subsequent async/wait call is skipped entirely. Split keys by mode so deferred cannot block event recording, and include mode in the cached payload.

-  // deduplicate lead events – only record 1 unique event for the same customer and event name
-  // TODO: Maybe we can replace this to rely only on MySQL directly since we're checking the customer above?
-  const ok = await redis.set(
-    `trackLead:${workspace.id}:${customerExternalId}:${stringifiedEventName}`,
+  // deduplicate by (customer,event,kind) where kind ∈ {deferred,event}
+  const dedupeSuffix = mode === "deferred" ? "deferred" : "event";
+  const dedupeKey = `trackLead:${workspace.id}:${customerExternalId}:${stringifiedEventName}:${dedupeSuffix}`;
+  const ok = await redis.set(
-    {
+    dedupeKey,
+    {
       timestamp: Date.now(),
       clickId,
       eventName,
       customerExternalId,
       customerName,
       customerEmail,
       customerAvatar,
+      mode,
     },
     {
       ex: 60 * 60 * 24 * 7, // cache for 1 week
       nx: true,
     },
   );

---

170-177: Avatar uploads can be orphaned for existing customers; use existing id for path and persist DB update

When customer exists, avatar path is built with a new finalCustomerId and upload runs without updating DB → orphaned file and stale avatar. Derive path from existing customer.id when present and update avatar after upload.

-  const finalCustomerId = createId({ prefix: "cus_" });
-  const finalCustomerName =
+  const newCustomerId = createId({ prefix: "cus_" });
+  const finalCustomerName =
     customerName || customerEmail || generateRandomName();
-  const finalCustomerAvatar =
-    customerAvatar && !isStored(customerAvatar)
-      ? `${R2_URL}/customers/${finalCustomerId}/avatar_${nanoid(7)}`
-      : customerAvatar;
+  const avatarCustomerId = customer?.id ?? newCustomerId;
+  const nextAvatarPath =
+    customerAvatar && !isStored(customerAvatar)
+      ? `${R2_URL}/customers/${avatarCustomerId}/avatar_${nanoid(7)}`
+      : customer?.avatar ?? customerAvatar ?? null;
@@
-    customer = await prisma.customer.create({
+    customer = await prisma.customer.create({
       data: {
-        id: finalCustomerId,
+        id: newCustomerId,
         name: finalCustomerName,
         email: customerEmail,
-        avatar: finalCustomerAvatar,
+        avatar: nextAvatarPath,
         externalId: customerExternalId,
         projectId: workspace.id,
         projectConnectId: workspace.stripeConnectId,
         clickId: clickData.click_id,
         linkId: clickData.link_id,
         country: clickData.country,
         clickedAt: new Date(clickData.timestamp + "Z"),
       },
     });
-    console.log(`customer created: ${JSON.stringify(customer, null, 2)}`);
   }
@@
-        if (
-          customerAvatar &&
-          !isStored(customerAvatar) &&
-          finalCustomerAvatar
-        ) {
+        if (customerAvatar && !isStored(customerAvatar) && nextAvatarPath) {
           // persist customer avatar to R2
           await storage.upload(
-            finalCustomerAvatar.replace(`${R2_URL}/`, ""),
+            nextAvatarPath.replace(`${R2_URL}/`, ""),
             customerAvatar,
             {
               width: 128,
               height: 128,
             },
           );
+          if (customer && customer.avatar !== nextAvatarPath) {
+            await prisma.customer.update({
+              where: { id: customer.id },
+              data: { avatar: nextAvatarPath },
+            });
+          }
         }

Also applies to: 241-255, 178-196

---

178-196: Remove PII logging (customer dump)

Logging the full customer object leaks PII to production logs. Delete this log or guard/sanitize.

-      console.log(`customer created: ${JSON.stringify(customer, null, 2)}`);

---

224-231: Remove noisy log; may include PII in response

Drop the “lead event recorded” console.log.

-        if (mode === "async") {
-          const res = await recordLead(createLeadEventPayload(customer.id));
-          console.log("lead event recorded:", res);
-        }
+        if (mode === "async") {
+          await recordLead(createLeadEventPayload(customer.id));
+        }

---

262-289: Update customer leads count to keep per-customer stats consistent

Post-processing bumps link and workspace but not customer.leads. Increment it in the same Promise.all.

-          const [link, _project] = await Promise.all([
+          const [link, _project, _customer] = await Promise.all([
             // update link leads count
             prisma.link.update({
@@
             }),
             // update workspace events usage
             prisma.project.update({
@@
             }),
+            // update customer leads count
+            prisma.customer.update({
+              where: { id: customer!.id },
+              data: {
+                leads: { increment: eventQuantity ?? 1 },
+              },
+            }),
           ]);

---

328-336: Idempotency race: second request can 404 before customer is persisted; add cached fallback

If a duplicate request arrives after NX succeeds but before the first write, customer is null and we 404. Fall back to the cached dedupe payload to return a stable 200.

-  if (!customer) {
-    throw new DubApiError({
-      code: "not_found",
-      message: `Customer not found for externalId: ${customerExternalId}`,
-    });
-  }
+  if (!customer) {
+    const baseKey = `trackLead:${workspace.id}:${customerExternalId}:${stringifiedEventName}`;
+    const cached =
+      (await redis.get<any>(`${baseKey}:event`)) ??
+      (await redis.get<any>(`${baseKey}:deferred`));
+    if (cached?.clickId) {
+      const lead = trackLeadResponseSchema.parse({
+        click: { id: cached.clickId },
+        customer: {
+          name: cached.customerName ?? null,
+          email: cached.customerEmail ?? null,
+          avatar: cached.customerAvatar ?? null,
+          externalId: customerExternalId,
+        },
+      });
+      return {
+        ...lead,
+        clickId: cached.clickId,
+        customerName: lead.customer.name,
+        customerEmail: lead.customer.email,
+        customerAvatar: lead.customer.avatar,
+      };
+    }
+    throw new DubApiError({
+      code: "not_found",
+      message: `Customer not found for externalId: ${customerExternalId}`,
+    });
+  }

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

313-323: Gate webhook delivery by workspace.webhookEnabled

Avoid unnecessary work when webhooks are disabled at the workspace level.

-          await sendWorkspaceWebhook({
+          if (workspace.webhookEnabled) {
+            await sendWorkspaceWebhook({
               trigger: "lead.created",
               data: transformLeadEventData({
                 ...clickData,
                 eventName,
                 link,
                 customer,
               }),
               workspace,
-          });
+            });
+          }

---

233-240: rawBody may contain PII; consider sanitizing before logging

If rawBody includes emails/names, you’ll persist PII. Log only whitelisted fields or mask sensitive ones.

-        await logConversionEvent({
+        const safeBody = JSON.stringify(
+          {
+            eventName,
+            eventQuantity,
+            customerExternalId,
+            clickId,
+            mode,
+            metadata,
+          },
+        );
+        await logConversionEvent({
           workspace_id: workspace.id,
           link_id: clickData.link_id,
           path: "/track/lead",
-          body: JSON.stringify(rawBody),
+          body: safeBody,
         });

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/tests/tracks/track-lead.test.ts (1)

87-119: Test doesn’t verify that deferred → async actually records the lead

Currently only the payload is asserted; missed side-effects let a regression slip (e.g., dedupe blocking async record).

Minimal clarity tweak and a side-effect assertion:

   const response2 = await http.post<TrackLeadResponse>({
     path: "/track/lead",
     body: {
       eventName: "Mode=Deferred Signup",
       customerExternalId: customer2.externalId,
+      mode: "async",
     },
   });

Consider additionally asserting that link.leads (or workspace.usage) increments after response2.

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

87-94: Avatar path may orphan uploads for existing customers

When customer exists, avatar path still uses a brand new finalCustomerId. Use the existing customer.id for pathing.

-  const finalCustomerId = createId({ prefix: "cus_" });
+  const finalCustomerId = createId({ prefix: "cus_" });
   const finalCustomerName =
     customerName || customerEmail || generateRandomName();
-  const finalCustomerAvatar =
-    customerAvatar && !isStored(customerAvatar)
-      ? `${R2_URL}/customers/${finalCustomerId}/avatar_${nanoid(7)}`
-      : customerAvatar;
+  const avatarCustomerId = customer?.id ?? finalCustomerId;
+  const finalCustomerAvatar =
+    customerAvatar && !isStored(customerAvatar)
+      ? `${R2_URL}/customers/${avatarCustomerId}/avatar_${nanoid(7)}`
+      : customer?.avatar ?? customerAvatar ?? null;

Also, after uploading for an existing customer, update customer.avatar if it differs.

---

262-289: Increment customer.leads alongside link/project

Keep per-customer stats consistent with link/workspace updates.

-          const [link, _project] = await Promise.all([
+          const [link, _project, _customer] = await Promise.all([
             // update link leads count
             prisma.link.update({
               where: {
                 id: clickData.link_id,
               },
               data: {
                 leads: {
                   increment: eventQuantity ?? 1,
                 },
               },
               include: includeTags,
             }),
 
             // update workspace events usage
             prisma.project.update({
               where: {
                 id: workspace.id,
               },
               data: {
                 usage: {
                   increment: eventQuantity ?? 1,
                 },
               },
             }),
+            // update customer leads count
+            prisma.customer.update({
+              where: { id: customer!.id },
+              data: { leads: { increment: eventQuantity ?? 1 } },
+            }),
           ]);

---

178-196: Remove PII logging of customer objects

console.log leaks PII (name/email/etc.) to prod logs. Remove it.

       customer = await prisma.customer.create({
         data: {
           id: finalCustomerId,
           name: finalCustomerName,
           email: customerEmail,
           avatar: finalCustomerAvatar,
           externalId: customerExternalId,
           projectId: workspace.id,
           projectConnectId: workspace.stripeConnectId,
           clickId: clickData.click_id,
           linkId: clickData.link_id,
           country: clickData.country,
           clickedAt: new Date(clickData.timestamp + "Z"),
         },
       });
-      console.log(`customer created: ${JSON.stringify(customer, null, 2)}`);

---

229-231: Remove verbose lead event logging

Avoid dumping event responses to logs.

-          const res = await recordLead(createLeadEventPayload(customer.id));
-          console.log("lead event recorded:", res);
+          await recordLead(createLeadEventPayload(customer.id));

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

267-268: Whitelist customer fields in response

Avoid leaking extra customer fields by passing only schema-allowed properties.

-    customer,
+    customer: customer
+      ? {
+          id: customer.id,
+          name: customer.name,
+          email: customer.email,
+          avatar: customer.avatar,
+          externalId: customer.externalId,
+        }
+      : null,

apps/web/tests/tracks/track-lead.test.ts (1)

154-175: Also assert eventQuantity side-effects

Validate that leads/usage increased by 2 to catch ingestion regressions.

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

132-133: Nit: comment typo

“from the from” → “from the”.

-    // get the referral link from the from the clickData
+    // get the referral link from the clickData

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

68-85: Deferred vs. event dedupe key conflation blocks the second call

The same Redis NX key is used for both the “deferred” priming call and the actual event call, so the second call is skipped and no lead/stats/webhooks run. Use separate keys per mode to keep flows independent.

-  // deduplicate lead events – only record 1 unique event for the same customer and event name
-  // TODO: Maybe we can replace this to rely only on MySQL directly since we're checking the customer above?
-  const ok = await redis.set(
-    `trackLead:${workspace.id}:${customerExternalId}:${stringifiedEventName}`,
+  // deduplicate per flow – don't let a deferred priming call block the actual event
+  const dedupeSuffix = mode === "deferred" ? "deferred" : "event";
+  const dedupeKey = `trackLead:${workspace.id}:${customerExternalId}:${stringifiedEventName}:${dedupeSuffix}`;
+  const ok = await redis.set(
+    dedupeKey,
     {
       timestamp: Date.now(),
       clickId,
       eventName,
       customerExternalId,
       customerName,
       customerEmail,
-      customerAvatar,
+      customerAvatar,
+      mode,
     },
     {
       ex: 60 * 60 * 24 * 7, // cache for 1 week
       nx: true,
     },
   );

---

240-254: Persisted avatar should update existing customer.avatar

After uploading, update the DB for existing customers so the record points to the stored asset.

-        if (
-          customerAvatar &&
-          !isStored(customerAvatar) &&
-          finalCustomerAvatar
-        ) {
+        if (customerAvatar && !isStored(customerAvatar) && nextAvatarPath) {
           // persist customer avatar to R2
           await storage.upload(
-            finalCustomerAvatar.replace(`${R2_URL}/`, ""),
+            nextAvatarPath.replace(`${R2_URL}/`, ""),
             customerAvatar,
             {
               width: 128,
               height: 128,
             },
           );
+          if (customer && customer.avatar !== nextAvatarPath) {
+            await prisma.customer.update({
+              where: { id: customer.id },
+              data: { avatar: nextAvatarPath },
+            });
+          }
         }

---

87-94: Avatar uploads can be orphaned; path should use existing customer.id and update DB

Avatar path is derived from a new ID even for existing customers, and the DB isn’t updated after uploading — leading to orphaned blobs. Use the existing customer.id when present and persist the new path.

-  const finalCustomerId = createId({ prefix: "cus_" });
+  const newCustomerId = createId({ prefix: "cus_" });
   const finalCustomerName =
     customerName || customerEmail || generateRandomName();
-  const finalCustomerAvatar =
-    customerAvatar && !isStored(customerAvatar)
-      ? `${R2_URL}/customers/${finalCustomerId}/avatar_${nanoid(7)}`
-      : customerAvatar;
+  const avatarCustomerId = customer?.id ?? newCustomerId;
+  const nextAvatarPath =
+    customerAvatar && !isStored(customerAvatar)
+      ? `${R2_URL}/customers/${avatarCustomerId}/avatar_${nanoid(7)}`
+      : customer?.avatar ?? customerAvatar ?? null;

---

178-195: Align created customer record with new avatar path variable names

Follow-through from the avatar fix: ensure created record uses the new IDs/paths.

-      customer = await prisma.customer.create({
+      customer = await prisma.customer.create({
         data: {
-          id: finalCustomerId,
+          id: newCustomerId,
           name: finalCustomerName,
           email: customerEmail,
-          avatar: finalCustomerAvatar,
+          avatar: nextAvatarPath,
           externalId: customerExternalId,
           projectId: workspace.id,
           projectConnectId: workspace.stripeConnectId,
           clickId: clickData.click_id,
           linkId: clickData.link_id,
           country: clickData.country,
           clickedAt: new Date(clickData.timestamp + "Z"),
         },
       });

---

261-288: Keep per-customer stats consistent: increment customer.leads too

Only link and workspace usage are incremented. Update the customer’s leads count alongside.

-          const [link, _project] = await Promise.all([
+          const [link, _project, _customer] = await Promise.all([
             // update link leads count
             prisma.link.update({
               where: {
                 id: clickData.link_id,
               },
               data: {
                 leads: {
                   increment: eventQuantity ?? 1,
                 },
               },
               include: includeTags,
             }),

             // update workspace events usage
             prisma.project.update({
               where: {
                 id: workspace.id,
               },
               data: {
                 usage: {
                   increment: eventQuantity ?? 1,
                 },
               },
             }),
+            // update customer leads count
+            prisma.customer.update({
+              where: { id: customer!.id },
+              data: { leads: { increment: eventQuantity ?? 1 } },
+            }),
           ]);

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

289-303: eventQuantity > 1 maps multiple lead events to a single commission eventId

When recording multiple events, using one eventId in commissions can mislead cross-references. Prefer omitting eventId when quantity > 1.

           await createPartnerCommission({
             event: "lead",
             programId: link.programId,
             partnerId: link.partnerId,
             linkId: link.id,
-            eventId: leadEventId,
+            eventId: eventQuantity ? undefined : leadEventId,
             customerId: customer.id,
             quantity: eventQuantity ?? 1,
             context: {
               customer: {
                 country: customer.country,
               },
             },
           });

---

52-64: Deferred flow requires clickId, which limits the “priming” use-case

Throwing when clickId is absent prevents a first “deferred” call from creating/priming a new customer. If that’s intentional, clarify in docs and error text; otherwise, allow a true priming call (cache payload, return 202-like response, and create on the actual event).

Would you like a patch to support a no-clickId “priming” request (store payload under the deferred dedupe key and short-circuit without Tinybird lookups)?

---

42-50: Narrow the select on findUnique to reduce I/O

Only id/clickId/avatar are read later. Use select to cut payload and index load.

-  let customer = await prisma.customer.findUnique({
-    where: {
-      projectId_externalId: {
-        projectId: workspace.id,
-        externalId: customerExternalId,
-      },
-    },
-  });
+  let customer = await prisma.customer.findUnique({
+    where: {
+      projectId_externalId: {
+        projectId: workspace.id,
+        externalId: customerExternalId,
+      },
+    },
+    select: { id: true, clickId: true, avatar: true, country: true },
+  });

---

232-239: rawBody may contain PII; consider redaction before logging

logConversionEvent persists the full request body. Mask common fields (email, name, identifiers) to avoid sensitive data leakage in analytics logs.

If helpful, I can add a small redaction util and wire it here.

---

156-176: Guard eventQuantity

Ensure zod clamps to a sane range (e.g., 1–100) to avoid excessive fan-out and cost. If not already enforced in the schema, add min/max.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

275-302: Also increment the customer’s leads count to keep per-customer stats in sync

Link and workspace are updated, but the customer’s leads isn’t.

-          const [link, _project] = await Promise.all([
+          const [link, _project, _customer] = await Promise.all([
             // update link leads count
             prisma.link.update({
@@
             }),
+            // update customer leads count
+            prisma.customer.update({
+              where: { id: customer!.id },
+              data: {
+                leads: {
+                  increment: eventQuantity ?? 1,
+                },
+              },
+            }),
           ]);

---

66-74: Avatar uploads can be orphaned for existing customers; use existing customer.id and persist DB after upload

Path uses a new ID even when the customer exists, and the DB isn’t updated after upload.

   const finalCustomerName =
     customerName || customerEmail || generateRandomName();
-  const finalCustomerAvatar =
-    customerAvatar && !isStored(customerAvatar)
-      ? `${R2_URL}/customers/${finalCustomerId}/avatar_${nanoid(7)}`
-      : customerAvatar;
+  const avatarCustomerId = customer?.id ?? finalCustomerId;
+  const finalCustomerAvatar =
+    customerAvatar && !isStored(customerAvatar)
+      ? `${R2_URL}/customers/${avatarCustomerId}/avatar_${nanoid(7)}`
+      : customer?.avatar ?? customerAvatar ?? null;
@@
         // persist customer avatar to R2
         await storage.upload(
           finalCustomerAvatar.replace(`${R2_URL}/`, ""),
           customerAvatar,
           {
             width: 128,
             height: 128,
           },
         );
+        // ensure DB points to the uploaded asset for existing customers
+        if (customer && customer.avatar !== finalCustomerAvatar) {
+          await prisma.customer.update({
+            where: { id: customer.id },
+            data: { avatar: finalCustomerAvatar },
+          });
+        }

Also applies to: 254-268

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

138-138: Nit: comment typo

“from the from the” → “from the”.

-    // get the referral link from the from the clickData
+    // get the referral link from the clickData

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

66-73: Potential issue with avatar path generation for existing customers

The finalCustomerAvatar path uses finalCustomerId even when the customer already exists. This could create inconsistent avatar paths and potential orphaned uploads when updating existing customers.

Consider using the existing customer's ID when available:

+const avatarCustomerId = customer?.id ?? finalCustomerId;
 const finalCustomerAvatar =
   customerAvatar && !isStored(customerAvatar)
-    ? `${R2_URL}/customers/${finalCustomerId}/avatar_${nanoid(7)}`
+    ? `${R2_URL}/customers/${avatarCustomerId}/avatar_${nanoid(7)}`
     : customerAvatar;

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

341-352: Handle potential null customer in response

When customer is null (which could happen in edge cases), the fallback uses finalCustomerName and other properties, but there's a potential issue with the response structure.

Consider ensuring customer is always populated or handle the null case more explicitly:

 return trackLeadResponseSchema.parse({
   click: {
     id: clickId,
   },
-  customer: customer ?? {
+  customer: customer ? {
+    name: customer.name,
+    email: customer.email,
+    avatar: customer.avatar,
+    externalId: customer.externalId,
+  } : {
     name: finalCustomerName,
     email: customerEmail || null,
     avatar: finalCustomerAvatar || null,
     externalId: customerExternalId,
   },
 });

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

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

275-301: Keep per-customer stats consistent: increment customer.leads too

Mirror link/project increments on the customer to avoid skewed dashboards.

-          const [link, _project] = await Promise.all([
+          const [link, _project, _customer] = await Promise.all([
             // update link leads count
             prisma.link.update({
@@
             }),
 
             // update workspace events usage
             prisma.project.update({
@@
             }),
+            // update customer leads count
+            prisma.customer.update({
+              where: { id: customer!.id },
+              data: { leads: { increment: qty } },
+            }),
           ]);

---

66-73: Avatar uploads can orphan for existing customers; use existing id and persist path

Reintroducing prior note: derive the avatar path from customer.id when available and update DB after upload to avoid dangling files.

@@
-  const finalCustomerId = createId({ prefix: "cus_" });
+  const finalCustomerId = createId({ prefix: "cus_" });
   const finalCustomerName =
     customerName || customerEmail || generateRandomName();
-  const finalCustomerAvatar =
-    customerAvatar && !isStored(customerAvatar)
-      ? `${R2_URL}/customers/${finalCustomerId}/avatar_${nanoid(7)}`
-      : customerAvatar;
+  const avatarCustomerId = customer?.id ?? finalCustomerId;
+  const nextAvatarPath =
+    customerAvatar && !isStored(customerAvatar)
+      ? `${R2_URL}/customers/${avatarCustomerId}/avatar_${nanoid(7)}`
+      : customer?.avatar ?? customerAvatar ?? null;
@@
       customer = await prisma.customer.upsert({
@@
         create: {
           id: finalCustomerId,
           name: finalCustomerName,
           email: customerEmail,
-          avatar: finalCustomerAvatar,
+          avatar: nextAvatarPath,
@@
         update: {},
       });
@@
-        if (
-          customerAvatar &&
-          !isStored(customerAvatar) &&
-          finalCustomerAvatar
-        ) {
+        if (customerAvatar && !isStored(customerAvatar) && nextAvatarPath) {
           // persist customer avatar to R2
           await storage.upload(
-            finalCustomerAvatar.replace(`${R2_URL}/`, ""),
+            nextAvatarPath.replace(`${R2_URL}/`, ""),
             customerAvatar,
             {
               width: 128,
               height: 128,
             },
           );
+          // ensure existing customers point to the uploaded asset
+          if (customer && customer.avatar !== nextAvatarPath) {
+            await prisma.customer.update({
+              where: { id: customer.id },
+              data: { avatar: nextAvatarPath },
+            });
+          }
         }
@@
   return trackLeadResponseSchema.parse({
     click: {
       id: clickId,
     },
-    customer: customer ?? {
+    customer: customer ?? {
       name: finalCustomerName,
-      email: customerEmail || null,
-      avatar: finalCustomerAvatar || null,
+      email: customerEmail || null,
+      avatar: nextAvatarPath || null,
       externalId: customerExternalId,
     },
   });

Also applies to: 184-209, 254-268, 341-351

apps/web/tests/tracks/track-lead.test.ts (1)

87-119: Set mode='async' on the second call and assert a side-effect.

Without explicitly passing mode: "async", the second call may rely on defaults and can be misread if dedupe prevents recording. Make intent explicit; also consider asserting a side-effect (e.g., usage increment/webhook fired) to prove the deferred→async flow actually records.

     const response2 = await http.post<TrackLeadResponse>({
       path: "/track/lead",
       body: {
         eventName: "Mode=Deferred Signup",
         customerExternalId: customer2.externalId,
+        mode: "async",
       },
     });

If the harness exposes a way to verify persistence/usage increments, add an assertion after response2 to confirm the lead was recorded.

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

48-55: Unify early-return payloads with the response schema

The two early returns still handcraft objects. To keep a single contract and catch type drift, parse them through trackSaleResponseSchema too.

@@
-    if (!ok) {
-      return {
-        eventName,
-        customer: null,
-        sale: null,
-      };
-    }
+    if (!ok) {
+      return trackSaleResponseSchema.parse({
+        eventName,
+        customer: null,
+        sale: null,
+      });
+    }
@@
-    return {
-      eventName,
-      customer: null,
-      sale: null,
-    };
+    return trackSaleResponseSchema.parse({
+      eventName,
+      customer: null,
+      sale: null,
+    });

Also applies to: 77-82

apps/web/tests/tracks/track-lead-client.test.ts (1)

47-52: Make the assertion resilient to future fields/normalization.

Strict equality on the entire customer object is brittle if the API adds fields or normalizes email/avatar. Prefer partial match.

-    expect(leadResponse).toStrictEqual({
+    expect(leadResponse).toMatchObject({
       click: {
         id: clickId,
       },
-      customer: customer,
+      customer: expect.objectContaining({
+        externalId: customer.externalId,
+        name: customer.name,
+        email: customer.email,
+        avatar: customer.avatar,
+      }),
     });

apps/web/tests/tracks/track-lead.test.ts (2)

66-85: Good idempotency check; consider codifying update semantics.

Add a follow-up duplicate call with changed non-key fields (e.g., name/email) to assert whether duplicates with the same customerExternalId update or preserve original values. This locks behavior and prevents regressions.

---

154-175: Exercise eventQuantity edge cases and effects.

Add a negative-path test (e.g., eventQuantity: 0 or < 0) and, if possible, a side-effect assertion that quantity >1 impacts downstream counts/ingestion.

Example additional test (placement outside this block is fine):

test("rejects non-positive eventQuantity", async () => {
  const customer = randomCustomer();
  const res = await http.post<TrackLeadResponse>({
    path: "/track/lead",
    body: {
      clickId: trackedClickId,
      eventName: "Start Trial",
      customerExternalId: customer.externalId,
      customerName: customer.name,
      customerEmail: customer.email,
      customerAvatar: customer.avatar,
      eventQuantity: 0,
    },
  });
  expect(res.status).toBeGreaterThanOrEqual(400);
});

Also consider changing the helper to allow additive fields:

// Update expectValidLeadResponse to use objectContaining
expect(response.data).toMatchObject({
  click: { id: clickId },
  customer: expect.objectContaining(customer),
});

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro