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

60-76: Idempotency race: no lock → duplicate sales possible under concurrency.

Two requests with the same invoiceId can pass the checks before the cache is written and both record a sale. Add a per-workspace+invoice lock using SET NX with a short TTL and fall back to cached/minimal response when the lock isn’t acquired. Also parse cached values via the response schema.

Suggested patch:

   // Return idempotent response if invoiceId is already processed
   if (invoiceId) {
-    const [oldKeyValue, newKeyValue] = await redis.mget(legacyKey, resultKey);
+    const legacyKey = `dub_sale_events:invoiceId:${invoiceId}`;
+    const resultKey = `trackSale:${workspace.id}:invoiceId:${invoiceId}`;
+    const lockKey = `${resultKey}:lock`;
+    const [oldKeyValue, newKeyValue] = await redis.mget(legacyKey, resultKey);
 
-    if (newKeyValue) {
-      return newKeyValue;
+    if (newKeyValue) {
+      return trackSaleResponseSchema.parse(newKeyValue);
     } else if (oldKeyValue) {
       return {
         eventName,
         customer: null,
         sale: null,
       };
     }
+
+    // Acquire lock to prevent double-processing (expires automatically)
+    const acquired = await redis.set(lockKey, 1, { nx: true, ex: 60 });
+    if (!acquired) {
+      // Another worker is handling this invoice; best-effort read
+      const cached = await redis.get(resultKey);
+      if (cached) return trackSaleResponseSchema.parse(cached);
+      return { eventName, customer: null, sale: null };
+    }
   }

Reference for SET options (nx, ex): Upstash TS docs. (upstash.com)

---

548-558: metadata can be undefined → Zod parse failure.

trackSaleResponseSchema.sale.metadata is nullable, not optional; passing undefined will fail validation and 500 the request. Default to null.

   const trackSaleResponse = trackSaleResponseSchema.parse({
     eventName,
     customer,
     sale: {
       amount,
       currency,
       invoiceId,
       paymentProcessor,
-      metadata,
+      metadata: metadata ?? null,
     },
   });

---

67-75: Validate cached response before returning; avoid returning any.

When returning newKeyValue, parse/cast to the response schema to ensure shape consistency and type-safety.

-    if (newKeyValue) {
-      return newKeyValue;
+    if (newKeyValue) {
+      return trackSaleResponseSchema.parse(newKeyValue);
     }

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

274-301: eventQuantity=0 bug: payload vs. counters diverge.

createLeadEventPayload uses a truthy check (records once when 0), while counters use eventQuantity ?? 1 (increments by 0). This records one event but increments zero — inconsistent.

Apply a single sanitized quantity and use it everywhere (payload, counters, commissions):

@@
-  let isDuplicateEvent = false;
+  let isDuplicateEvent = false;
+  // Normalize quantity early; 0/negative -> 1 (paired with schema tightening)
+  const qty = typeof eventQuantity === "number" && eventQuantity > 0
+    ? Math.floor(eventQuantity)
+    : 1;
@@
-    const createLeadEventPayload = (customerId: string) => {
+    const createLeadEventPayload = (customerId: string) => {
       const basePayload = {
@@
-      return eventQuantity
-        ? Array(eventQuantity)
+      return qty > 1
+        ? Array(qty)
             .fill(null)
             .map(() => ({
               ...basePayload,
               event_id: nanoid(16),
             }))
         : basePayload;
     };
@@
-              data: {
-                leads: {
-                  increment: eventQuantity ?? 1,
-                },
-              },
+              data: { leads: { increment: qty } },
@@
-              data: {
-                usage: {
-                  increment: eventQuantity ?? 1,
-                },
-              },
+              data: { usage: { increment: qty } },
@@
-              quantity: eventQuantity ?? 1,
+              quantity: qty,

Also consider tightening the schema as suggested in leads.ts to forbid non-positive values.