packages/ui/src/icons/nucleo/cloud.tsx (1)

12-28: Deduplicate SVG attributes; remove redundant fill and push shared stroke to the group

Both paths repeat identical stroke and fill props, while the parent group sets an unused fill. Centralize shared attributes on the and simplify the paths.

Apply this diff:

-      <g fill="currentColor">
-        <path
-          d="M13.464,6.891c-.186-2.314-2.102-4.141-4.464-4.141-2.485,0-4.5,2.015-4.5,4.5,0,.35,.049,.686,.124,1.013-1.597,.067-2.874,1.374-2.874,2.987,0,1.657,1.343,3,3,3h7.75c2.071,0,3.75-1.679,3.75-3.75,0-1.736-1.185-3.182-2.786-3.609Z"
-          fill="none"
-          stroke="currentColor"
-          strokeLinecap="round"
-          strokeLinejoin="round"
-          strokeWidth="1.5"
-        />
-        <path
-          d="M9.705,8c.687-.767,1.684-1.25,2.795-1.25,.333,0,.657,.059,.964,.141"
-          fill="none"
-          stroke="currentColor"
-          strokeLinecap="round"
-          strokeLinejoin="round"
-          strokeWidth="1.5"
-        />
+      <g fill="none" stroke="currentColor" strokeLinecap="round" strokeLinejoin="round" strokeWidth="1.5">
+        <path d="M13.464,6.891c-.186-2.314-2.102-4.141-4.464-4.141-2.485,0-4.5,2.015-4.5,4.5,0,.35,.049,.686,.124,1.013-1.597,.067-2.874,1.374-2.874,2.987,0,1.657,1.343,3,3,3h7.75c2.071,0,3.75-1.679,3.75-3.75,0-1.736-1.185-3.182-2.786-3.609Z" />
+        <path d="M9.705,8c.687-.767,1.684-1.25,2.795-1.25,.333,0,.657,.059,.964,.141" />
       </g>

apps/web/lib/actions/partners/update-partner-profile.ts (3)

97-122: Avoid shadowing outer name and improve readability in map callbacks

The callback param name shadows the outer name field. Rename to value (or similar) in each map to reduce confusion.

Apply this diff:

-          ...(industryInterests && {
+          ...(industryInterests && {
             industryInterests: {
               deleteMany: {},
-              create: industryInterests.map((name) => ({
-                industryInterest: name,
+              create: industryInterests.map((value) => ({
+                industryInterest: value,
               })),
             },
           }),
 
-          ...(preferredEarningStructures && {
+          ...(preferredEarningStructures && {
             preferredEarningStructures: {
               deleteMany: {},
-              create: preferredEarningStructures.map((name) => ({
-                preferredEarningStructure: name,
+              create: preferredEarningStructures.map((value) => ({
+                preferredEarningStructure: value,
               })),
             },
           }),
 
-          ...(salesChannels && {
+          ...(salesChannels && {
             salesChannels: {
               deleteMany: {},
-              create: salesChannels.map((name) => ({
-                salesChannel: name,
+              create: salesChannels.map((value) => ({
+                salesChannel: value,
               })),
             },
           }),

---

181-184: Harden error handling: error is unknown

Accessing error.message directly can throw if error isn’t an Error. Guard it to avoid masking the real failure.

Apply this diff:

-    } catch (error) {
-      console.error(error);
-
-      throw new Error(error.message);
-    }
+    } catch (error) {
+      console.error(error);
+      const message =
+        error instanceof Error ? error.message : "Failed to update partner profile";
+      throw new Error(message);
+    }

---

225-228: Align error messaging with actual constraints (include company name)

You also gate on companyName changes, but the message mentions only country/profile type. Include company name to reduce confusion.

-      "Since you've already received payouts on Dub, you cannot change your country or profile type. Please contact support to update those fields.",
+      "Since you've already received payouts on Dub, you cannot change your country, profile type, or company name. Please contact support to update those fields.",

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
PR: dubinc/dub#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
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: TWilson023
PR: dubinc/dub#2872
File: apps/web/lib/actions/partners/update-partner-profile.ts:97-104
Timestamp: 2025-09-24T15:57:55.259Z
Learning: In the Dub codebase, the team prefers to maintain consistency with existing patterns for database operations, even if there are theoretical improvements available. The deleteMany: {} pattern for relation updates is an accepted approach that the team considers low-risk.

Learnt from: TWilson023
PR: dubinc/dub#2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:218-219
Timestamp: 2025-09-24T15:51:28.818Z
Learning: In the Dub codebase, OG_AVATAR_URL concatenation with partner names follows a consistent pattern throughout the application where names are used directly without URL encoding. This is an established codebase-wide pattern.

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#2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.387Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.