apps/web/app/(ee)/api/workflows/partner-approved/route.ts (3)

292-299: Skip Step 4 when the partner has no group to avoid unnecessary DB calls and accidental broad fetches.

You already guard on groupId in Steps 1–2. Mirror that here to short‑circuit.

Apply this diff:

     await context.run("trigger-draft-bounty-submission-creation", async () => {
       logger.info({
         message:
           "Started executing workflow step 'trigger-draft-bounty-submission-creation'.",
         data: input,
       });
 
+      if (!groupId) {
+        logger.info({
+          message: `Skipping draft bounty submission creation: partner ${partnerId} has no group.`,
+        });
+        return;
+      }

---

300-307: Make Step 4 best‑effort: catch and log instead of failing the whole workflow.

This is a downstream trigger; let the cron/job enforce idempotency and retries.

Apply this diff:

-      await triggerDraftBountySubmissionCreation({
-        programId,
-        partnerIds: [partnerId],
-      });
+      try {
+        await triggerDraftBountySubmissionCreation({
+          programId,
+          partnerIds: [partnerId],
+        });
+      } catch (err) {
+        logger.error({
+          message: "Failed to trigger draft bounty submission creation.",
+          data: {
+            programId,
+            partnerId,
+            error: err instanceof Error ? err.message : String(err),
+          },
+        });
+        return;
+      }

---

300-303: Idempotency confirmed — DB unique + skipDuplicates; QStash dedupe optional

• apps/web/app/(ee)/api/cron/bounties/create-draft-submissions/route.ts uses prisma.bountySubmission.createMany({ skipDuplicates: true }).
• packages/prisma/schema/bounty.prisma has @@unique([bountyId, partnerId]) so duplicate drafts from retries/duplicate events are blocked.
• Note: the unique index is on [bountyId, partnerId] (not including status); change that only if you need a different semantics (e.g., allow multiple submissions across statuses).
• Upstash QStash supports deduplication (deduplicationId or contentBasedDeduplication); consider adding deduplicationId to the qstash.publishJSON calls that enqueue this job (apps/web/lib/api/bounties/trigger-draft-bounty-submissions.ts) or via the qstash wrapper (apps/web/lib/webhook/qstash.ts TODO) for extra queue-level protection (optional).

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/web/app/(ee)/api/bounties/route.ts (2)

240-242: Gate draft‑submission scheduling on workflow existence

Avoid scheduling a cron that will immediately no‑op when no workflow is created (performance bounties without a condition).

-    const shouldScheduleDraftSubmissions =
-      bounty.type === "performance" && bounty.performanceScope === "lifetime";
+    const shouldScheduleDraftSubmissions =
+      bounty.type === "performance" &&
+      bounty.performanceScope === "lifetime" &&
+      !!bounty.workflowId;

---

266-282: Optional: add idempotency key to QStash calls

If a client retries POST /bounties, duplicate cron jobs could be enqueued. Prefer idempotency keys where supported.

If QStash supports a header/body idempotency key, include the bounty.id to dedupe.

apps/web/tests/bounties/index.test.ts (1)

35-58: Add negative test: missing performanceScope should 400

Covers validation branch added in the API.

Would you like me to add a test asserting 400 with message “performanceScope must be set for performance bounties.”?

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/[bountyId]/bounty-submissions-table.tsx (3)

83-87: Clarify operator precedence in sortBy expression

Parentheses make intent obvious and avoid future regressions.

-  const sortBy =
-    searchParams.get("sortBy") || bounty?.type === "performance"
-      ? metricColumnId
-      : "createdAt";
+  const sortBy =
+    searchParams.get("sortBy") ||
+    (bounty?.type === "performance" ? metricColumnId : "createdAt");

---

236-245: Ensure reviewedAt is a Date before passing to UserRowItem

API likely returns ISO strings; cast to Date to match prop type and avoid subtle TZ issues.

-                return row.original.reviewedAt ? (
+                return row.original.reviewedAt ? (
                   <UserRowItem
                     user={row.original.user!}
-                    date={row.original.reviewedAt}
+                    date={new Date(row.original.reviewedAt as any)}
                     label={
                       row.original.status === "approved"
                         ? "Approved at"
                         : "Rejected at"
                     }
                   />

---

312-317: Row count should use a total from API for paginated lists

For submission bounties, using current page length misreports total rows. Either return totalCount from API or compute separately.

Do you want me to wire totalCount from the route and update rowCount accordingly?

apps/web/app/(ee)/api/cron/bounties/create-draft-submissions/route.ts (3)

23-25: Fix route comment to match actual path

Avoid confusion during ops/debugging.

-// POST /api/cron/bounties/create-submissions
+// POST /api/cron/bounties/create-draft-submissions

---

176-183: Defensive error logging: error may not be an Error

Avoid accessing error.message blindly.

-    await log({
-      message: "New bounties submissions cron failed. Error: " + error.message,
-      type: "errors",
-    });
+    await log({
+      message:
+        "New bounties submissions cron failed. Error: " +
+        (error instanceof Error ? error.message : JSON.stringify(error)),
+      type: "errors",
+    });

---

54-60: Start‑time guard may be too coarse

Ten‑minute cushion could delay valid runs if QStash delivers slightly early/late. Consider a smaller threshold (e.g., 1–2 minutes) or rely solely on notBefore.

Want me to tune this and add tests around boundary times?

apps/web/lib/zod/schemas/bounties.ts (2)

22-28: Consider relocating or removing this constant.

The AI summary indicates this REJECT_BOUNTY_SUBMISSION_REASONS export is removed later in the file as part of consolidation. If this constant is no longer needed as a public export, consider removing it entirely or moving it to a more appropriate location.

---

73-78: Document or hide immutable performanceScope on bounty updates.

Verified: updateBountySchema omits performanceScope and the PATCH handler does not update it; creation requires performanceScope. The edit form still exposes a performanceScope control that will be ignored by the API.

Action: document that performanceScope is immutable after creation, or remove/disable the performanceScope field in the edit flow to avoid user confusion.

Locations: apps/web/lib/zod/schemas/bounties.ts (updateBountySchema), apps/web/app/(ee)/api/bounties/[bountyId]/route.ts (PATCH), apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/add-edit-bounty-sheet.tsx (form/defaults/performSubmit), apps/web/ui/partners/bounties/bounty-logic.tsx (performanceScope control).

apps/web/lib/api/workflows/execute-award-bounty-action.ts (3)

80-90: Submission precheck could be cheaper and more robust.

If the (bountyId, partnerId) relationship is unique, fetch only one row and only status to reduce payload. Also consider re-checking status right before awarding (now addressed by the atomic claim).

-  if (submissions.length > 0) {
-    const submission = submissions[0];
+  if (submissions.length > 0) {
+    const submission = submissions[0]; // consider selecting only `status`
     if (submission.status !== "draft") {
       console.log(
         `Partner ${partnerId} has an existing submission for bounty ${bounty.id} with status ${submission.status}.`,
       );
       return;
     }
   }

---

108-126: Simplify attribute extraction (nit).

finalContext is only used to derive count. Inline the attribute read for clarity.

-  const finalContext: Partial<
-    Record<WorkflowConditionAttribute, number | null>
-  > = {
-    ...(condition.attribute === "totalLeads" && {
-      totalLeads: context.current?.leads ?? 0,
-    }),
-    ...(condition.attribute === "totalConversions" && {
-      totalConversions: context.current?.conversions ?? 0,
-    }),
-    ...(condition.attribute === "totalSaleAmount" && {
-      totalSaleAmount: context.current?.saleAmount ?? 0,
-    }),
-    ...(condition.attribute === "totalCommissions" && {
-      totalCommissions: context.current?.commissions ?? 0,
-    }),
-  };
-
-  const count = finalContext[condition.attribute] ?? 0;
+  const map: Record<WorkflowConditionAttribute, number | null> = {
+    totalLeads: context.current?.leads ?? 0,
+    totalConversions: context.current?.conversions ?? 0,
+    totalSaleAmount: context.current?.saleAmount ?? 0,
+    totalCommissions: context.current?.commissions ?? 0,
+  };
+  const count = map[condition.attribute] ?? 0;

---

144-147: Confirmed: performanceCount is Int — coerce and clamp 'count' to a non‑negative integer before upsert.

packages/prisma/schema/bounty.prisma defines performanceCount Int? (packages/prisma/schema/bounty.prisma:68). The upsert in apps/web/lib/api/workflows/execute-award-bounty-action.ts reads count and uses it to increment (lines ~125–146). Keep the schema as Int (currency is stored in cents elsewhere), but coerce/validate the value before using it:

-  const count = finalContext[condition.attribute] ?? 0;
+  const raw = finalContext[condition.attribute] ?? 0;
+  const parsed = Number(raw);
+  const count = Number.isFinite(parsed) ? Math.max(0, Math.round(parsed)) : 0;

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: devkiran
PR: dubinc/dub#2833
File: apps/web/lib/actions/partners/approve-bounty-submission.ts:53-61
Timestamp: 2025-09-12T17:31:10.548Z
Learning: In approve-bounty-submission.ts, the logic `bounty.rewardAmount ?? rewardAmount` is intentional. Bounties with preset reward amounts should use those fixed amounts, and the rewardAmount override parameter is only used when bounty.rewardAmount is null/undefined (for custom reward bounties). This follows the design pattern where bounties are either "flat rate" (fixed amount) or "custom" (variable amount set during approval).

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/api/bounties/get-bounty-or-throw.ts:53-63
Timestamp: 2025-08-26T15:38:48.173Z
Learning: In bounty-related code, getBountyOrThrow returns group objects with { id } field (transformed from BountyGroup.groupId), while other routes working directly with BountyGroup Prisma records use the actual groupId field. This is intentional - getBountyOrThrow abstracts the join table details.

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/actions/partners/create-bounty-submission.ts:105-112
Timestamp: 2025-08-26T14:32:33.851Z
Learning: Non-performance bounties are required to have submissionRequirements. In create-bounty-submission.ts, it's appropriate to let the parsing fail if submissionRequirements is null for non-performance bounties, as this indicates a data integrity issue that should be caught.

Learnt from: TWilson023
PR: dubinc/dub#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.

apps/web/tests/bounties/index.test.ts (1)

102-122: Reduce duplication or clarify test intent.

This test sets performanceScope: "new" again even though performanceBounty already includes it, and mainly differs by omitting performanceCondition. Either rename to reflect intent or remove the redundant override.

Option A — clarify intent and drop duplicate field:

- test("POST /bounties - performance based with performanceScope set to new", async () => {
+ test("POST /bounties - performance based without performanceCondition", async () => {
    const { status, data: bounty } = await http.post<Bounty>({
      path: "/bounties",
      body: {
        ...performanceBounty,
        groupIds: [E2E_PARTNER_GROUP.id],
-       performanceScope: "new",
      },
    });

Option B — keep as-is but add an assertion explaining behavior when performanceCondition is omitted.

apps/web/lib/api/workflows/execute-award-bounty-action.ts (3)

62-71: Minor: clarify activity log message.

For startsAt > now, “not yet active” is clearer than “no longer active.”

-    console.log(`Bounty ${bounty.id} is no longer active.`);
+    console.log(
+      bounty.startsAt && bounty.startsAt > now
+        ? `Bounty ${bounty.id} is not yet active.`
+        : `Bounty ${bounty.id} is no longer active.`,
+    );

---

27-29: Validate program consistency (defense-in-depth).

Ensure bounty.programId === context.programId to avoid cross‑program awards if the wrong context is supplied.

   const { bountyId } = action.data;
   const { partnerId, groupId } = context;
 
+  if (context.programId && bounty?.programId && bounty.programId !== context.programId) {
+    console.error(
+      `Context programId (${context.programId}) does not match bounty.programId (${bounty.programId}).`,
+    );
+    return;
+  }

---

109-132: performanceCount holds both counts and currency (cents) — rename or document

• Verified: packages/prisma/schema/bounty.prisma defines performanceCount as Int? and totalSaleAmount/totalCommissions are represented as integer cents across the codebase (no truncation/throw risk at runtime).
• Action: either rename the field (e.g., performanceValue / performanceAmount) and update DB + Zod + UI, or add explicit comments/typing and ensure formatting/divide-by-100 is applied where currency is shown. Key locations: packages/prisma/schema/bounty.prisma, apps/web/lib/api/workflows/execute-award-bounty-action.ts (≈lines 109–132), apps/web/lib/zod/schemas/bounties.ts, and related UI files (bounty-performance.tsx, bounty-submissions-table.tsx).

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/actions/partners/create-bounty-submission.ts:105-112
Timestamp: 2025-08-26T14:32:33.851Z
Learning: Non-performance bounties are required to have submissionRequirements. In create-bounty-submission.ts, it's appropriate to let the parsing fail if submissionRequirements is null for non-performance bounties, as this indicates a data integrity issue that should be caught.

Learnt from: devkiran
PR: dubinc/dub#2833
File: apps/web/lib/actions/partners/approve-bounty-submission.ts:53-61
Timestamp: 2025-09-12T17:31:10.548Z
Learning: In approve-bounty-submission.ts, the logic `bounty.rewardAmount ?? rewardAmount` is intentional. Bounties with preset reward amounts should use those fixed amounts, and the rewardAmount override parameter is only used when bounty.rewardAmount is null/undefined (for custom reward bounties). This follows the design pattern where bounties are either "flat rate" (fixed amount) or "custom" (variable amount set during approval).

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/api/bounties/get-bounty-or-throw.ts:53-63
Timestamp: 2025-08-26T15:38:48.173Z
Learning: In bounty-related code, getBountyOrThrow returns group objects with { id } field (transformed from BountyGroup.groupId), while other routes working directly with BountyGroup Prisma records use the actual groupId field. This is intentional - getBountyOrThrow abstracts the join table details.

apps/web/lib/webhook/sample-events/bounty-updated.json (1)

12-12: Add a populated “performance” example sample.

This sample keeps performanceScope: null. Consider adding an additional sample (e.g., apps/web/lib/webhook/sample-events/bounty-updated.performance.json) demonstrating a non-null performanceScope value and any related fields so integrators can test real payloads end‑to‑end. Keep enum strings exactly as defined in the public schema.

If you confirm the canonical enum values, I can draft the sample file for you.

apps/web/scripts/migrations/backfill-performance-bounty-submissions.ts (3)

8-15: Avoid unnecessary writes; log the migration impact.

Update only rows not already set to lifetime, and log how many were touched.

-  await prisma.bounty.updateMany({
+  const { count } = await prisma.bounty.updateMany({
     where: {
-      type: "performance",
+      type: "performance",
+      performanceScope: { not: "lifetime" },
     },
     data: {
       performanceScope: "lifetime",
     },
   });
+  console.log(`Set performanceScope=lifetime on ${count} bounties`);

---

17-21: Don’t load entire records; page through IDs.

Fetching full rows does extra I/O and memory. At minimum, select only id. For large tables, prefer cursor pagination.

Minimal change:

-  const bounties = await prisma.bounty.findMany({
-    where: {
-      type: "performance",
-    },
-  });
+  const bounties = await prisma.bounty.findMany({
+    where: { type: "performance" },
+    select: { id: true },
+    orderBy: { id: "asc" },
+  });

If volume is high, switch to cursor‑paged processing (outside this hunk). I can draft that if helpful.

---

13-14: Use the Prisma enum BountyPerformanceScope instead of a string literal

Import the generated enum and replace the string literal to avoid typos — enum values are new and lifetime. Location: apps/web/scripts/migrations/backfill-performance-bounty-submissions.ts (lines 13–14). Example: add
import { BountyPerformanceScope } from "@dub/prisma/client"
and use
performanceScope: BountyPerformanceScope.lifetime

apps/web/ui/partners/bounties/bounty-logic.tsx (5)

37-39: Fix invalid HTML: div inside span.

A block-level div nested in a span is invalid and can cause layout quirks. Make the container a span.

-        <div className="inline-flex items-center gap-1">
+        <span className="inline-flex items-center gap-1">
 ...
-        </div>
+        </span>

Also applies to: 78-78

---

19-19: Reset dependent value when attribute changes (avoid stale currency/int mix).

If the user switches between currency and count attributes, carry‑over values can be invalid/misleading. Reset the threshold value on attribute change. This aligns with prior learning to reset dependent fields when the parent changes.

-  const { control, watch } = useAddEditBountyForm();
+  const { control, watch, setValue } = useAddEditBountyForm();

               <InlineBadgePopoverMenu
                 selectedValue={field.value}
-                onSelect={field.onChange}
-                items={WORKFLOW_ATTRIBUTES.map((attribute) => ({
-                  text: WORKFLOW_ATTRIBUTE_LABELS[attribute].toLowerCase(),
-                  value: attribute,
-                }))}
+                onSelect={(attr) => {
+                  field.onChange(attr);
+                  // Clear threshold so the user explicitly sets a valid value for the new attribute
+                  setValue("performanceCondition.value", undefined, {
+                    shouldDirty: true,
+                    shouldValidate: true,
+                  });
+                }}
+                items={WORKFLOW_ATTRIBUTES.map((attr) => ({
+                  text: WORKFLOW_ATTRIBUTE_LABELS[attr].toLowerCase(),
+                  value: attr,
+                }))}
               />

Also applies to: 55-77

---

117-126: Apply money handlers only for currency; hint numeric keyboard.

The money key/input handlers should not run for count attributes; add inputMode for better mobile UX.

       <input
         className={cn(
           "block w-full rounded-md border-neutral-300 px-1.5 py-1 text-neutral-900 placeholder-neutral-400 focus:border-neutral-500 focus:outline-none focus:ring-neutral-500 sm:w-32 sm:text-sm",
           isCurrency ? "pl-4 pr-12" : "pr-7",
         )}
+        inputMode={isCurrency ? "decimal" : "numeric"}
         {...register("performanceCondition.value", {
           required: true,
           setValueAs: (value: string) => (value === "" ? undefined : +value),
           min: 0,
-          onChange: handleMoneyInputChange,
+          onChange: isCurrency ? handleMoneyInputChange : undefined,
         })}
         onKeyDown={(e) => {
           if (e.key === "Enter") {
             e.preventDefault();
             setIsOpen(false);
             return;
           }
-
-          handleMoneyKeyDown(e);
+          if (isCurrency) {
+            handleMoneyKeyDown(e);
+          }
         }}
       />

Also applies to: 127-136

---

138-141: Avoid hard‑coded “USD”.

If multi‑currency is (or will be) supported, source the currency code/symbol from org/program settings or formatter helpers.

Would you like me to search the codebase for an org/program currency setting and suggest a small adapter? I can provide a targeted patch once confirmed.

---

39-54: Scope UX: add placeholder and friendlier labels

Show a placeholder when unset and map enum values to human-friendly labels. Verified performanceScope is an enum used by server logic and the UI defaults to "new", so this is UI-only and preserves semantics.

-              <InlineBadgePopover text={field.value} invalid={!field.value}>
+              <InlineBadgePopover
+                text={field.value ? SCOPE_LABELS[field.value as keyof typeof SCOPE_LABELS] : "scope"}
+                invalid={!field.value}
+              >
                 <InlineBadgePopoverMenu
                   selectedValue={field.value}
                   onSelect={field.onChange}
-                  items={[
-                    { text: "new", value: "new" },
-                    { text: "lifetime", value: "lifetime" },
-                  ]}
+                  items={[
+                    { text: SCOPE_LABELS.new, value: "new" },
+                    { text: SCOPE_LABELS.lifetime, value: "lifetime" },
+                  ]}
                 />
               </InlineBadgePopover>

Add once near the top of the file (outside the selected range):

const SCOPE_LABELS = { new: "current period", lifetime: "all time" } as const;

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
PR: dubinc/dub#2673
File: apps/web/ui/partners/rewards/rewards-logic.tsx:268-275
Timestamp: 2025-07-30T15:29:54.131Z
Learning: In apps/web/ui/partners/rewards/rewards-logic.tsx, when setting the entity field in a reward condition, dependent fields (attribute, operator, value) should be reset rather than preserved because different entities (customer vs sale) have different available attributes. Maintaining existing fields when the entity changes would create invalid state combinations and confusing UX.

packages/prisma/client.ts (1)

4-4: Expose BountyPerformanceScope via the client wrapper — LGTM.

This lines up the web layer with the new enum.

If your intent is to curate a stable surface, consider dropping the top-level export * to avoid duplicate re-exports and potential linter noise. Example:

-export * from "@prisma/client";
+// curated surface
 export {
   BountyPerformanceScope,
   BountySubmissionRejectionReason,
   BountySubmissionStatus,
   BountyType,
   CommissionStatus,
   CommissionType,
   EventType,
   FolderType,
   FolderUserRole,
   InvoiceStatus,
   NotificationEmailType,
   PartnerBannedReason,
   PartnerLinkStructure,
   PartnerProfileType,
   PartnerRole,
   PartnerStatus,
   PayoutStatus,
   Prisma,
   ProgramEnrollmentStatus,
   RewardStructure,
   Role,
   WebhookReceiver,
   WorkflowTrigger,
   WorkflowTriggerType,
 } from "@prisma/client";

apps/web/lib/zod/schemas/bounties.ts (6)

70-71: Gate performanceScope to performance bounties.

Prevent invalid combos by validating type/scope together.

 export const createBountySchema = z.object({
   ...
   performanceCondition: workflowConditionSchema.nullish(),
-  performanceScope: z.nativeEnum(BountyPerformanceScope).nullish(),
+  performanceScope: z.nativeEnum(BountyPerformanceScope).nullish(),
 }).superRefine((data, ctx) => {
+  // Only allow performanceScope when the bounty type is PERFORMANCE
+  if (data.type !== BountyType.PERFORMANCE && data.performanceScope != null) {
+    ctx.addIssue({
+      code: z.ZodIssueCode.custom,
+      message: "performanceScope is only allowed for performance bounties",
+      path: ["performanceScope"],
+    });
+  }
 });

---

75-79: Reject unknown update keys to avoid silent drops (e.g., performanceScope).

Right now, omitted keys get stripped; explicit performanceScope on PATCH would be silently ignored.

 export const updateBountySchema = createBountySchema
   .omit({
     // omit fields that cannot be updated after creation
     type: true,
     performanceScope: true,
   })
-  .partial();
+  .partial()
+  .strict(); // reject unknown keys

---

98-101: Normalize nullability default for performanceScope.

Keep output shape stable by defaulting null.

-  performanceScope: z.nativeEnum(BountyPerformanceScope).nullable(),
+  performanceScope: z.nativeEnum(BountyPerformanceScope).nullable().default(null),

---

122-123: Constrain performanceCount to a non-negative integer.

Counts shouldn’t be fractional or negative.

-  performanceCount: z.number().nullable(),
+  performanceCount: z.number().int().min(0).nullable(),

---

156-161: Use the enum for rejectionReason in the read schema too.

Aligns read/write types and prevents arbitrary strings from slipping through.

 export const rejectBountySubmissionSchema = z.object({
   workspaceId: z.string(),
   submissionId: z.string(),
   rejectionReason: z.nativeEnum(BountySubmissionRejectionReason),
   rejectionNote: z.string().trim().max(500).optional(),
 });

And in BountySubmissionSchema:

-  rejectionReason: z.string().nullable(),
+  rejectionReason: z.nativeEnum(BountySubmissionRejectionReason).nullable(),

---

22-28: Keep and type REJECT_BOUNTY_SUBMISSION_REASONS against the rejection-reason enum

Used in several places (UI dropdowns + reject action) — do not remove. Change the declaration to a typed map so keys stay in sync with the schema/enum.

Files: apps/web/lib/zod/schemas/bounties.ts (declare); consumers include apps/web/ui/partners/reject-bounty-submission-modal.tsx, apps/web/ui/partners/bounties/claim-bounty-modal.tsx, apps/web/lib/actions/partners/reject-bounty-submission.ts, and the bounty-submission-details sheet.

Suggested approach (example):

• If a type exists:
  export const REJECT_BOUNTY_SUBMISSION_REASONS: Record<BountySubmissionRejectionReason, string> = { ... };
• Otherwise derive from the schema:
  type RejectionReason = z.infer['rejectionReason'];
  export const REJECT_BOUNTY_SUBMISSION_REASONS: Record<RejectionReason, string> = { ... };

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/actions/partners/create-bounty-submission.ts:105-112
Timestamp: 2025-08-26T14:32:33.851Z
Learning: Non-performance bounties are required to have submissionRequirements. In create-bounty-submission.ts, it's appropriate to let the parsing fail if submissionRequirements is null for non-performance bounties, as this indicates a data integrity issue that should be caught.

Learnt from: devkiran
PR: dubinc/dub#2833
File: apps/web/lib/actions/partners/approve-bounty-submission.ts:53-61
Timestamp: 2025-09-12T17:31:10.548Z
Learning: In approve-bounty-submission.ts, the logic `bounty.rewardAmount ?? rewardAmount` is intentional. Bounties with preset reward amounts should use those fixed amounts, and the rewardAmount override parameter is only used when bounty.rewardAmount is null/undefined (for custom reward bounties). This follows the design pattern where bounties are either "flat rate" (fixed amount) or "custom" (variable amount set during approval).

Learnt from: TWilson023
PR: dubinc/dub#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.

apps/web/lib/api/workflows/execute-award-bounty-action.ts (7)

93-99: Approved-submission check assumes a single row; clarify uniqueness or harden lookup.

If submissions can exist per period post-refactor, this check will incorrectly block future-period awards. Query by the active period key or enforce one submission per (bounty, partner, period).

Option:

• Add where: { partnerId, periodKey: context.periodKey } and check that row’s status only.

---

35-49: Narrow the submissions include to required fields.

Load only id and status to reduce payload.

   include: {
     program: true,
     groups: true,
-    submissions: {
-      where: {
-        partnerId,
-      },
-    },
+    submissions: {
+      where: { partnerId },
+      select: { id: true, status: true },
+    },
   },

---

105-121: Reduce branching in finalContext construction.

Build from a map to simplify and avoid future mismatches.

-  const finalContext: Partial<
-    Record<WorkflowConditionAttribute, number | null>
-  > = {
-    ...(condition.attribute === "totalLeads" && {
-      totalLeads: context.current?.leads ?? 0,
-    }),
-    ...(condition.attribute === "totalConversions" && {
-      totalConversions: context.current?.conversions ?? 0,
-    }),
-    ...(condition.attribute === "totalSaleAmount" && {
-      totalSaleAmount: context.current?.saleAmount ?? 0,
-    }),
-    ...(condition.attribute === "totalCommissions" && {
-      totalCommissions: context.current?.commissions ?? 0,
-    }),
-  };
+  const attributeMap: Record<WorkflowConditionAttribute, number | null> = {
+    totalLeads: context.current?.leads ?? 0,
+    totalConversions: context.current?.conversions ?? 0,
+    totalSaleAmount: context.current?.saleAmount ?? 0,
+    totalCommissions: context.current?.commissions ?? 0,
+  };
+  const finalContext = { [condition.attribute]: attributeMap[condition.attribute] };

---

122-123: Naming nit: performanceCount may store amounts.

When storing sale amounts/commissions, consider a generic name (e.g., metricValue) for clarity across metrics.

---

147-160: Log message clarity.

“does not meet the trigger condition” → include the evaluated value and threshold/operator for debuggability.

Example:

• value, operator, expected, attribute, submissionId.

---

124-145: Optional: avoid an extra DB round‑trip when just setting latest value.

If you adopt “set latest period-to-date value,” consider using update with select to return only performanceCount and id.

---

125-145: Offer: full period migration/backfill plan.

I can draft the Prisma migration (new field + index), backfill script, and code updates across cron seeding, API reads, and UI filters.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: devkiran
PR: dubinc/dub#2833
File: apps/web/lib/actions/partners/approve-bounty-submission.ts:53-61
Timestamp: 2025-09-12T17:31:10.548Z
Learning: In approve-bounty-submission.ts, the logic `bounty.rewardAmount ?? rewardAmount` is intentional. Bounties with preset reward amounts should use those fixed amounts, and the rewardAmount override parameter is only used when bounty.rewardAmount is null/undefined (for custom reward bounties). This follows the design pattern where bounties are either "flat rate" (fixed amount) or "custom" (variable amount set during approval).

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/api/bounties/get-bounty-or-throw.ts:53-63
Timestamp: 2025-08-26T15:38:48.173Z
Learning: In bounty-related code, getBountyOrThrow returns group objects with { id } field (transformed from BountyGroup.groupId), while other routes working directly with BountyGroup Prisma records use the actual groupId field. This is intentional - getBountyOrThrow abstracts the join table details.

Learnt from: TWilson023
PR: dubinc/dub#2736
File: apps/web/lib/actions/partners/create-bounty-submission.ts:105-112
Timestamp: 2025-08-26T14:32:33.851Z
Learning: Non-performance bounties are required to have submissionRequirements. In create-bounty-submission.ts, it's appropriate to let the parsing fail if submissionRequirements is null for non-performance bounties, as this indicates a data integrity issue that should be caught.