apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts (1)

55-64: Consider adding a limit to prevent performance issues.

The previouslyProcessedPayouts query has no take limit. While it's scoped to partners in the current batch (max 100 partners), each partner could accumulate many previously processed payouts if transfers have been failing. This could lead to performance degradation in edge cases.

Consider adding a reasonable limit or an index to optimize this query:

 const previouslyProcessedPayouts = await prisma.payout.findMany({
   where: {
     status: "processed",
     stripeTransferId: null,
     partnerId: {
       in: currentInvoicePayouts.map((p) => p.partnerId),
     },
   },
   include: commonInclude,
+  take: 1000, // reasonable upper bound to prevent performance issues
 });

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (2)

22-24: Spec/docs mismatch: “batches of 100” but current run can process up to 200 (100 Stripe + 100 PayPal).

Either enforce 100 total per run (split remaining between providers) or update wording to “up to 200 (100 per provider)”. This was raised earlier and still applies.

---

91-116: Don’t use the stale pre-batch count to schedule next batch; re-count after writes, add a short QStash delay and dedup.

• invoice._count.payouts was fetched before processing; using it can schedule unnecessary follow-ups or miss when >100 but processed fully this run.
• Re-count remaining “processing” payouts after Promise.allSettled and schedule only if remaining > 0.
• Add a small delay (e.g., "5s") to avoid reading from replicas before writes are visible and enable content-based deduplication to prevent duplicate follow-ups. QStash supports delay and contentBasedDeduplication in publishJSON. (upstash.com)

Apply:

-    if (invoice._count.payouts > 100) {
-      console.log(
-        "More than 100 payouts found for invoice, scheduling next batch...",
-      );
-      const qstashResponse = await qstash.publishJSON({
-        url: `${APP_DOMAIN_WITH_NGROK}/api/cron/payouts/charge-succeeded`,
-        body: {
-          invoiceId: invoiceId,
-        },
-      });
-      if (qstashResponse.messageId) {
-        console.log(
-          `Message sent to Qstash with id ${qstashResponse.messageId}`,
-        );
-      } else {
-        console.error("Error sending message to Qstash", qstashResponse);
-      }
-
-      return logAndRespond(
-        `Completed processing current batch of payouts for invoice ${invoiceId}. Next batch scheduled.`,
-      );
-    }
-
-    return logAndRespond(
-      `Completed processing all payouts for invoice ${invoiceId}.`,
-    );
+    // Re-count remaining after processing to avoid using stale counts
+    const fresh = await prisma.invoice.findUnique({
+      where: { id: invoiceId },
+      select: {
+        _count: {
+          select: {
+            payouts: { where: { status: "processing" } },
+          },
+        },
+      },
+    });
+    const remaining = fresh?._count.payouts ?? 0;
+
+    if (remaining > 0) {
+      await log({
+        message: `Remaining payouts (${remaining}) for invoice ${invoiceId}; scheduling next batch...`,
+        type: "cron",
+      });
+      const qstashResponse = await qstash.publishJSON({
+        url: `${APP_DOMAIN_WITH_NGROK}/api/cron/payouts/charge-succeeded`,
+        body: { invoiceId },
+        delay: "5s",
+        contentBasedDeduplication: true,
+      });
+      await log({
+        message: `QStash publish result: ${qstashResponse.messageId ?? "no messageId"}`,
+        type: "cron",
+      });
+      return logAndRespond(
+        `Completed current batch for invoice ${invoiceId}. Next batch scheduled.`,
+      );
+    }
+
+    return logAndRespond(`Completed processing all payouts for invoice ${invoiceId}.`);

Note: If you truly want “batches of 100 total”, expose a limit param on sendStripePayouts/sendPaypalPayouts and split the 100 between them; otherwise update PR/title/comments accordingly.

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (1)

2-7: Prefer structured logging/response helpers over console logs; keep usage consistent.

You import qstash, APP_DOMAIN_WITH_NGROK, log, and logAndRespond. Downstream you still use console.log/console.error; consider standardizing on log/logAndRespond for consistency and observability.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/paypal/webhook/payouts-item-failed.ts (1)

12-15: HELD and UNCLAIMED payouts will trigger incorrect failure emails.

Mapping HELD and UNCLAIMED to "processed" causes these payouts to bypass the early return at line 61 and proceed to send failure emails (lines 71-91) with the subject "Your recent partner payout failed."

However, these are temporary states, not actual failures:

• HELD: Payment on hold pending compliance review or risk assessment
• UNCLAIMED: Recipient hasn't claimed the payment yet (typically 30 days to claim)

Partners will receive misleading failure notifications for payouts that haven't actually failed.

Consider one of these solutions:

1. Keep these as "processing" to leverage batch retry logic
2. Add distinct "held" and "unclaimed" statuses with appropriate handling
3. Add a conditional check at line 61 to exclude these statuses from failure email flow:

-  if (payoutStatus === "processing") {
+  if (payoutStatus === "processing" || payoutStatus === "held" || payoutStatus === "unclaimed") {
     await log({
       message: `Paypal payout is stuck in processing for invoice ${invoiceId} and partner ${paypalEmail}. PayPal webhook status: ${body.event_type}.${
         failureReason ? ` Failure reason: ${failureReason}` : ""
       }`,
       type: "errors",
     });
     return; // we only send emails for failed payouts
   }

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (1)

91-112: Batch size inconsistency: Each batch can process up to 200 payouts.

The condition invoice._count.payouts > 100 checks if more than 100 payouts exist, but each batch actually processes up to 200 payouts:

• Stripe: up to 100 payouts (send-stripe-payouts.ts line 45)
• PayPal: up to 100 payouts (send-paypal-payouts.ts line 34)
• Total: up to 200 payouts per batch

This is inconsistent with the PR title "Handle payouts in batches of 100" and could cause confusion about actual batch capacity.

Consider one of these approaches:

Option 1: Adjust the threshold to match actual capacity:

-if (invoice._count.payouts > 100) {
+if (invoice._count.payouts > 200) {
   console.log(
-    "More than 100 payouts found for invoice, scheduling next batch...",
+    "More than 200 payouts found for invoice, scheduling next batch...",
   );

Option 2: Coordinate limits so each batch truly processes 100 total:

• Fetch Stripe payouts first with take: 100
• Calculate remaining: remaining = 100 - stripePayouts.length
• Fetch PayPal payouts with take: remaining

Option 3: Update PR title and documentation to reflect "batches of up to 200 payouts (100 per payment method)."

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts (1)

45-45: LGTM: Batch limit correctly applied to current invoice payouts.

The take: 100 limit aligns with the PR objective of processing payouts in batches of 100.

Consider also limiting the previouslyProcessedPayouts query (line 55) if a partner could accumulate a large number of unprocessed historical payouts. Currently, this query is unbounded and could fetch an arbitrarily large result set, potentially impacting performance:

 const previouslyProcessedPayouts = await prisma.payout.findMany({
   where: {
     status: "processed",
     stripeTransferId: null,
     partnerId: {
       in: currentInvoicePayouts.map((p) => p.partnerId),
     },
   },
   include: commonInclude,
+  take: 500, // reasonable upper bound for historical payouts per batch
 });

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-paypal-payouts.ts (1)

49-59: Add try-catch error handling around batch creation and status update to improve reliability and observability.

Verification confirms the "sent" status is properly handled throughout the payout lifecycle:

• ✅ Status is recognized across webhooks, UI, and type definitions (PayoutStatus enum from Prisma)
• ✅ Recovery mechanism exists: the Stripe webhook (payout-paid.ts) transitions "sent" → "completed" when payment arrives
• ✅ Implicit retry via cron: if the status update fails, payouts remain "processing" and are retried in the next batch

However, error handling remains missing. While idempotency is protected by PayPal's sender_item_id, wrapping the batch creation and status update in try-catch would improve observability and prevent silent failures from clouding logs.

 const batchPayout = await createPayPalBatchPayout({
   payouts,
   invoiceId,
 });

 console.log("PayPal batch payout created", batchPayout);

+try {
   // update the payouts to "sent" status
   const updatedPayouts = await prisma.payout.updateMany({
     where: {
       id: { in: payouts.map((p) => p.id) },
     },
     data: {
       status: "sent",
       paidAt: new Date(),
     },
   });
   console.log(`Updated ${updatedPayouts.count} payouts to "sent" status`);
+} catch (error) {
+  console.error("Failed to update payout statuses to 'sent'", error);
+  // Payouts will remain in "processing" and be retried in next batch
+  // PayPal's sender_item_id provides idempotency protection
+}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (1)

89-114: Re-count remaining payouts after updates; avoid stale threshold, align logs, and remove console.log.

Current check uses the pre-send count and a 100 threshold while each provider can take 100, leading to extra no-op invocations and confusing “100 vs 200” semantics. Prefer re-counting “processing” after updates to decide whether to schedule. Also use the shared log utility instead of console.log. Optional: add a small QStash delay if supported to smooth replica lag.

-    if (invoice._count.payouts > 100) {
-      console.log(
-        "More than 100 payouts found for invoice, scheduling next batch...",
-      );
-      const qstashResponse = await qstash.publishJSON({
-        url: `${APP_DOMAIN_WITH_NGROK}/api/cron/payouts/charge-succeeded`,
-        body: {
-          invoiceId: invoiceId,
-        },
-      });
-      if (qstashResponse.messageId) {
-        console.log(
-          `Message sent to Qstash with id ${qstashResponse.messageId}`,
-        );
-      } else {
-        // should never happen but just in case
-        await log({
-          message: `Error sending message to Qstash to schedule next batch of payouts for invoice ${invoiceId}: ${JSON.stringify(qstashResponse)}`,
-          type: "errors",
-        });
-      }
-
-      return logAndRespond(
-        `Completed processing current batch of payouts for invoice ${invoiceId}. Next batch scheduled.`,
-      );
-    }
-
-    return logAndRespond(
-      `Completed processing all payouts for invoice ${invoiceId}.`,
-    );
+    // Re-check remaining "processing" payouts after sender updates to avoid stale counts
+    const remaining = await prisma.payout.count({
+      where: { invoiceId, status: "processing" },
+    });
+    if (remaining > 0) {
+      await log({
+        message: `Remaining payouts=${remaining} for invoice ${invoiceId}; scheduling next batch…`,
+        type: "cron",
+      });
+      const qstashResponse = await qstash.publishJSON({
+        url: `${APP_DOMAIN_WITH_NGROK}/api/cron/payouts/charge-succeeded`,
+        body: { invoiceId },
+        // delay: 5, // optional: if QStash supports delay, consider a short delay to absorb replica lag
+      });
+      if (qstashResponse.messageId) {
+        await log({
+          message: `QStash messageId=${qstashResponse.messageId} scheduled for next batch (invoice ${invoiceId}).`,
+          type: "cron",
+        });
+      } else {
+        await log({
+          message: `Error scheduling next batch for invoice ${invoiceId}: ${JSON.stringify(qstashResponse)}`,
+          type: "errors",
+        });
+      }
+      return logAndRespond(
+        `Completed processing current batch of payouts for invoice ${invoiceId}. Next batch scheduled.`,
+      );
+    }
+    return logAndRespond(
+      `Completed processing all payouts for invoice ${invoiceId}.`,
+    );

Also applies to: 116-118

apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (1)

78-87: Capture and log failures from Promise.allSettled.

You await settlement but drop rejection reasons. Log them to aid ops without failing the whole job.

-    await Promise.allSettled([
-      sendStripePayouts({
-        invoiceId,
-        chargeId,
-      }),
-
-      sendPaypalPayouts({
-        invoiceId,
-      }),
-    ]);
+    const results = await Promise.allSettled([
+      sendStripePayouts({ invoiceId, chargeId }),
+      sendPaypalPayouts({ invoiceId }),
+    ]);
+    const failures = results.filter(
+      (r): r is PromiseRejectedResult => r.status === "rejected",
+    );
+    if (failures.length) {
+      await log({
+        message: `Payout tasks failed: ${failures
+          .map((f) => String(f.reason))
+          .join(" | ")
+          .slice(0, 1000)}`,
+        type: "errors",
+      });
+    }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro