apps/web/app/(ee)/api/cron/bounties/notify-partners/route.ts (2)

26-29: Consider making batch configuration environment-based.

The hardcoded constants are reasonable defaults, but making them configurable via environment variables would provide flexibility for production tuning without code changes.

Example:

const EMAIL_BATCH_SIZE = parseInt(process.env.BOUNTY_BATCH_SIZE || "100", 10);
const BATCH_DELAY_SECONDS = parseInt(process.env.BOUNTY_BATCH_DELAY || "2", 10);
const EXTENDED_DELAY_SECONDS = parseInt(process.env.BOUNTY_EXTENDED_DELAY || "30", 10);
const EXTENDED_DELAY_INTERVAL = parseInt(process.env.BOUNTY_EXTENDED_INTERVAL || "25", 10);

---

174-179: Remove redundant check and add explanatory comment.

The batchNumber > 0 check is redundant since batchNumber defaults to 1 and is always incremented. Additionally, the throttling strategy would benefit from a brief comment.

Apply this diff:

-      // Add BATCH_DELAY_SECONDS pause between each batch, and a longer EXTENDED_DELAY_SECONDS cooldown after every EXTENDED_DELAY_INTERVAL batches.
       let delay = 0;
-      if (batchNumber > 0 && batchNumber % EXTENDED_DELAY_INTERVAL === 0) {
+      // Apply extended delay every 25 batches (at batch 25, 50, 75, etc.) to prevent rate limiting
+      if (batchNumber % EXTENDED_DELAY_INTERVAL === 0) {
         delay = EXTENDED_DELAY_SECONDS;
       } else {
         delay = BATCH_DELAY_SECONDS;
       }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/cron/bounties/notify-partners/route.ts (1)

113-123: Critical: Change orderBy from id to createdAt for reliable pagination.

This issue was flagged in a previous review and remains unfixed. The id field uses CUID, which is cryptographically random and non-sequential. Ordering by id produces unpredictable, non-chronological results that make cursor-based pagination unreliable. Records may be skipped or processed multiple times across batches.

When changing to createdAt, you'll also need to update:

1. The orderBy clause (line 121)
2. The cursor field (line 117)
3. The startingAfter assignment (line 183)

Apply this diff:

-      take: EMAIL_BATCH_SIZE,
-      skip: startingAfter ? 1 : 0,
-      ...(startingAfter && {
-        cursor: {
-          id: startingAfter,
-        },
-      }),
       orderBy: {
-        id: "asc",
+        createdAt: "asc",
       },
+      take: EMAIL_BATCH_SIZE,
+      skip: startingAfter ? 1 : 0,
+      ...(startingAfter && {
+        cursor: {
+          createdAt: new Date(startingAfter),
+        },
+      }),

And update line 183:

-      startingAfter = programEnrollments[programEnrollments.length - 1].id;
+      startingAfter = programEnrollments[programEnrollments.length - 1].createdAt.toISOString();

apps/web/app/(ee)/api/cron/bounties/notify-partners/route.ts (1)

182-207: Batch continuation logic is mostly correct.

The delay calculation and batch enqueueing logic works properly. Extended delays are applied every 25 batches as intended.

For clarity, consider using a new variable name instead of reassigning the parameter:

     if (programEnrollments.length === EMAIL_BATCH_SIZE) {
-      startingAfter = programEnrollments[programEnrollments.length - 1].id;
+      const nextCursor = programEnrollments[programEnrollments.length - 1].id;

       // Add BATCH_DELAY_SECONDS pause between each batch, and a longer EXTENDED_DELAY_SECONDS cooldown after every EXTENDED_DELAY_INTERVAL batches.
       let delay = 0;
       if (batchNumber > 0 && batchNumber % EXTENDED_DELAY_INTERVAL === 0) {
         delay = EXTENDED_DELAY_SECONDS;
       } else {
         delay = BATCH_DELAY_SECONDS;
       }

       await qstash.publishJSON({
         url: `${APP_DOMAIN_WITH_NGROK}/api/cron/bounties/notify-partners`,
         method: "POST",
         delay,
         body: {
           bountyId,
-          startingAfter,
+          startingAfter: nextCursor,
           batchNumber: batchNumber + 1,
         },
       });

       return logAndRespond(
-        `Enqueued next batch (${startingAfter}) for bounty ${bountyId} to run after ${delay} seconds.`,
+        `Enqueued next batch (${nextCursor}) for bounty ${bountyId} to run after ${delay} seconds.`,
       );
     }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: devkiran
Repo: dubinc/dub PR: 2754
File: apps/web/lib/partnerstack/schemas.ts:47-52
Timestamp: 2025-08-16T11:14:00.667Z
Learning: The PartnerStack API always includes the `group` field in partner responses, so the schema should use `.nullable()` rather than `.nullish()` since the field is never omitted/undefined.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2857
File: apps/web/lib/actions/partners/update-program.ts:96-0
Timestamp: 2025-09-17T17:44:03.965Z
Learning: In apps/web/lib/actions/partners/update-program.ts, the team prefers to keep the messagingEnabledAt update logic simple by allowing client-provided timestamps rather than implementing server-controlled timestamp logic to avoid added complexity.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2736
File: apps/web/app/api/workspaces/[idOrSlug]/notification-preferences/route.ts:13-14
Timestamp: 2025-08-26T14:20:23.943Z
Learning: The updateNotificationPreference action in apps/web/lib/actions/update-notification-preference.ts already handles all notification preference types dynamically, including newBountySubmitted, through its schema validation using the notificationTypes enum and Prisma's dynamic field update pattern.