apps/web/lib/actions/partners/create-reward.ts (1)

21-29: Normalize description (trim and empty-to-null) before persisting

In apps/web/lib/actions/partners/create-reward.ts (lines 21–29 & 62–64), trim parsedInput.description, convert empty strings to null, and use that value in your Prisma call:

   .action(async ({ parsedInput, ctx }) => {
     const { …, description, … } = parsedInput;
+    const normalizedDescription =
+      typeof description === "string"
+        ? (description.trim() === "" ? null : description.trim())
+        : null;
     // …
     await prisma.reward.create({
       data: {
         // …
-        description: description || null,
+        description: normalizedDescription,
         // …
       },
     });

apps/web/lib/actions/partners/update-reward.ts (1)

18-19: Mirror description normalization on update; avoid losing Entered spaces and allow clearing.

Trims, converts empty-to-null, and makes update path consistent with create.

   .action(async ({ parsedInput, ctx }) => {
     const { workspace, user } = ctx;
     const { rewardId, amount, maxDuration, type, description, modifiers } =
       parsedInput;
+    const normalizedDescription =
+      typeof description === "string"
+        ? (description.trim() === "" ? null : description.trim())
+        : null;
@@
         amount,
         maxDuration,
-        description: description || null,
+        description: normalizedDescription,
         modifiers: modifiers === null ? Prisma.DbNull : modifiers,

Also applies to: 44-46

apps/web/lib/zod/schemas/rewards.ts (1)

153-154: Add server-validated constraints to description (trim + max length) and keep in sync with UI.

Prevents oversized text and whitespace-only values from reaching the DB.

Option A (minimal risk): keep schema as-is and rely on action-level normalization (see action diffs).

Option B (schema-level guard):

-  description: z.string().nullish(),
+  // Keep in sync with UI maxLength; adjust constant as needed.
+  description: z
+    .union([z.string(), z.null(), z.undefined()])
+    .transform((v) => (typeof v === "string" ? v.trim() : v))
+    .refine(
+      (v) => v == null || (typeof v === "string" && v.length <= 160),
+      "Description must be 160 characters or fewer.",
+    )
+    .transform((v) => (typeof v === "string" && v.length === 0 ? null : v)),

If you prefer a shared constant, I can add export const REWARD_DESCRIPTION_MAX_LEN = 160 and reference it in both schema and UI. Want me to push that follow-up?

apps/web/ui/partners/rewards/add-edit-reward-sheet.tsx (5)

436-452: Treat whitespace-only descriptions as invalid in UI.

Current checks consider " " valid (truthy). Use trim() for validity, and surface the trimmed value in the badge text.

-                        <InlineBadgePopover
-                          text={description || "Reward description"}
-                          invalid={!description}
-                        >
+                        <InlineBadgePopover
+                          text={description?.trim() || "Reward description"}
+                          invalid={!description?.trim()}
+                        >

---

369-375: Parse “Infinity” explicitly for clarity.

Number("Infinity") works but is implicit. Making it explicit improves readability.

-                              onSelect={(value) =>
-                                setValue("maxDuration", Number(value), {
+                              onSelect={(value) =>
+                                setValue(
+                                  "maxDuration",
+                                  value === "Infinity" ? Infinity : Number(value),
+                                  {
                                     shouldDirty: true,
-                                })
+                                  },
+                                )
                               }

---

398-419: Improve description toggle UX/accessibility.

• Tooltip can reflect the current action (Add vs Remove).
• Advertise state to assistive tech via aria-pressed/aria-expanded.

-                  <Tooltip
-                    content={"Add a custom reward description"}
-                    disabled={description !== null}
-                  >
+                  <Tooltip
+                    content={
+                      description === null
+                        ? "Add a custom reward description"
+                        : "Remove custom reward description"
+                    }
+                  >
@@
-                      <Button
+                      <Button
                         variant="secondary"
                         className={cn(
                           "size-7 p-0",
                           description !== null && "text-blue-600",
                         )}
                         icon={<Pen2 className="size-3.5" />}
+                        aria-pressed={description !== null}
+                        aria-expanded={description !== null}
                         onClick={() =>
                           setValue(
                             "description",
                             description === null ? "" : null,
                             { shouldDirty: true },
                           )
                         }
                       />

---

242-246: Remove noisy console log in production paths.

A toast is already shown; consider removing or gating the console.log.

-        console.log("parse error", error);
+        // console.error("reward condition parse error", error);

---

342-353: Amount badge validity: consider negative/NaN explicitly.

You mark invalid only on isNaN(amount). If negative amounts somehow slip past, the badge still looks valid. Not blocking, but consider also amount < 0.

-                        invalid={isNaN(amount)}
+                        invalid={isNaN(amount) || Number(amount) < 0}

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.

Learnt from: TWilson023
PR: dubinc/dub#2673
File: apps/web/ui/partners/rewards/add-edit-reward-sheet.tsx:56-66
Timestamp: 2025-07-30T15:25:13.936Z
Learning: In apps/web/ui/partners/rewards/add-edit-reward-sheet.tsx, the form schema uses partial condition objects to allow users to add empty/unconfigured condition fields without type errors, while submission validation uses strict schemas to ensure data integrity. This two-stage validation pattern improves UX by allowing progressive completion of complex forms.

Learnt from: devkiran
PR: dubinc/dub#2735
File: apps/web/lib/actions/partners/delete-reward.ts:33-41
Timestamp: 2025-08-14T05:17:51.825Z
Learning: In the partner groups system, a rewardId can only belong to one group, establishing a one-to-one relationship between rewards and groups. This means using Prisma's `update` method (rather than `updateMany`) is appropriate when updating groups by rewardId.

apps/web/lib/zod/schemas/rewards.ts (1)

136-144: Apply the same 100-char cap to RewardSchema for parity.

RewardSchema.description still accepts any length, creating inconsistency with createOrUpdateRewardSchema and enabling oversized values to slip through when validating reads or legacy data.

Apply:

-  description: z.string().nullish(),
+  description: z.string().max(100).nullish(),

If you'd like, I can add a quick Zod test to assert both schemas reject >100 chars and accept null/empty.

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

141-144: Type modifiers consistently across schemas.

RewardSchema.modifiers is z.any().nullish() while create/update uses rewardConditionsArraySchema. This loses validation on reads and increases risk of bad data.

-  modifiers: z.any().nullish(), // TODO: Fix this
+  modifiers: rewardConditionsArraySchema.nullish(),

---

140-142: Reuse maxDurationSchema in RewardSchema for consistency.

RewardSchema.maxDuration is a plain z.number().nullish(). Using the shared schema keeps constraints aligned across create/read/update.

-  maxDuration: z.number().nullish(),
+  maxDuration: maxDurationSchema,

---

157-164: Prefer enum constant over string literal.

Inside superRefine, set data.type with RewardStructure.flat to avoid drift if enum values change.

-      data.type = "flat";
+      data.type = RewardStructure.flat;

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro