Add PartnerNetworkStatus enum#3876
Open
steven-tey wants to merge 16 commits intomainfrom
Open
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughReplaces the partner discovery checklist with a network-approval flow: DB and Zod schema additions for PartnerNetworkStatus, renamed checklist helpers, new NetworkApprovalGuide UI and submit action, admin APIs/pages for network applications and trusted partners, and related consumer updates and cleanup. ChangesPartner Network Approval System
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsx (1)
143-156: 💤 Low value
ConditionalLinkspreadsPartial<HTMLProps<HTMLAnchorElement>>onto Next.jsLink— minor type mismatch.
HTMLProps<HTMLAnchorElement>and Next.jsLink's prop type are different shapes (Linkexpectshref: string | UrlObject, notstring | undefined). TypeScript may complain in strict mode when...restis spread. Consider usingComponentProps<typeof Link>instead, or an explicit union type:-function ConditionalLink({ - href, - className, - children, - ...rest -}: Partial<HTMLProps<HTMLAnchorElement>>) { +function ConditionalLink({ + href, + className, + children, + ...rest +}: Omit<ComponentProps<typeof Link>, "href"> & { href?: string }) {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/web/app/`(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsx around lines 143 - 156, The ConditionalLink component currently types its props as Partial<HTMLProps<HTMLAnchorElement>> which mismatches Next.js Link props and causes TypeScript errors when spreading ...rest; change the prop typing for ConditionalLink to use ComponentProps<typeof Link> (or a narrow union that matches Link's href type and anchor props) and include href as the Link-compatible type (string | UrlObject | undefined) so that spreading ...rest onto <Link> is type-safe; update the function signature and prop destructuring (the ConditionalLink identifier) to that new prop type and keep the same runtime logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@apps/web/app/`(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsx:
- Around line 21-38: Move all React hooks to the top of the component so they
run unconditionally: call useState (isExpanded, setIsExpanded) and
useConfirmModal (setShowConfirmModal, confirmModal) before the early return and
before invoking getNetworkProfileChecklistProgress. Keep the pure helper call
getNetworkProfileChecklistProgress guarded by a conditional/ternary that uses
partner ? getNetworkProfileChecklistProgress({ partner }) : { tasks: [],
completedCount: 0, totalCount: 0, isComplete: false } (or similar safe defaults)
so the rest of the render can use tasks/completedCount/totalCount/isComplete
without calling hooks conditionally. Ensure you still early-return null when
partner is absent if that’s required, but do not place any hook calls after that
return.
- Around line 35-37: The onConfirm handler currently only calls toast.success
and never submits the application; update the onConfirm in
network-approval-guide.tsx to call the server action
submitNetworkApplicationAction (await its result), then on success show
toast.success and ensure partner.networkStatus is updated (or refetch/refresh
the parent data) so it no longer remains "draft"; also handle and surface errors
by catching exceptions and calling toast.error with a helpful message if
submitNetworkApplicationAction fails.
---
Nitpick comments:
In
`@apps/web/app/`(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsx:
- Around line 143-156: The ConditionalLink component currently types its props
as Partial<HTMLProps<HTMLAnchorElement>> which mismatches Next.js Link props and
causes TypeScript errors when spreading ...rest; change the prop typing for
ConditionalLink to use ComponentProps<typeof Link> (or a narrow union that
matches Link's href type and anchor props) and include href as the
Link-compatible type (string | UrlObject | undefined) so that spreading ...rest
onto <Link> is type-safe; update the function signature and prop destructuring
(the ConditionalLink identifier) to that new prop type and keep the same runtime
logic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: bd6b5feb-d041-459d-beed-ba3b9e80bb20
📒 Files selected for processing (14)
apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsxapps/web/app/(ee)/partners.dub.co/(dashboard)/profile/page-client.tsxapps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-discovery-guide.tsxapps/web/app/(ee)/partners.dub.co/(dashboard)/profile/use-partner-discovery-requirements.tsapps/web/app/(ee)/partners.dub.co/(dashboard)/programs/marketplace/[programSlug]/header-controls.tsxapps/web/app/api/user/referrals-token/route.tsapps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/settings/billing/invoices/page.tsxapps/web/lib/actions/partners/create-program-application.tsapps/web/lib/network/get-network-approval-requirements.tsapps/web/lib/network/get-network-profile-checklist-progress.tsapps/web/lib/zod/schemas/partners.tspackages/prisma/schema/application.prismapackages/prisma/schema/partner.prismapackages/prisma/schema/tag.prisma
💤 Files with no reviewable changes (2)
- apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/use-partner-discovery-requirements.ts
- apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-discovery-guide.tsx
Comment on lines
+21
to
+38
| if (!partner) return null; | ||
|
|
||
| const { tasks, completedCount, totalCount, isComplete } = | ||
| getNetworkProfileChecklistProgress({ | ||
| partner, | ||
| }); | ||
|
|
||
| const [isExpanded, setIsExpanded] = useState(isComplete ? false : true); | ||
|
|
||
| const { setShowConfirmModal, confirmModal } = useConfirmModal({ | ||
| title: "Submit application", | ||
| description: | ||
| "Are you sure you want to submit your Dub Network application for review? You won't be able to make changes to your application after submitting it.", | ||
| confirmText: "Confirm submission", | ||
| onConfirm: () => { | ||
| toast.success("Application submitted successfully"); | ||
| }, | ||
| }); |
Contributor
There was a problem hiding this comment.
Critical: Rules of Hooks violation — useState and useConfirmModal called after an early return.
Hooks must always be used at the top level of a React function, before any early returns. Both useState (line 28) and useConfirmModal (line 30) are invoked only when partner is truthy, skipping them entirely on renders where partner is undefined. This will produce a runtime error: "React Hook 'useState' is called conditionally. React Hooks must be called in the exact same order in every component render."
Move all hooks above the early return and guard the pure-function call with a ternary:
🐛 Proposed fix
export function NetworkApprovalGuide() {
const { partner } = usePartnerProfile();
- if (!partner) return null;
-
- const { tasks, completedCount, totalCount, isComplete } =
- getNetworkProfileChecklistProgress({
- partner,
- });
-
- const [isExpanded, setIsExpanded] = useState(isComplete ? false : true);
-
- const { setShowConfirmModal, confirmModal } = useConfirmModal({
+ const { tasks, completedCount, totalCount, isComplete } = partner
+ ? getNetworkProfileChecklistProgress({ partner })
+ : { tasks: [], completedCount: 0, totalCount: 0, isComplete: false };
+
+ const [isExpanded, setIsExpanded] = useState(!isComplete);
+
+ const { setShowConfirmModal, confirmModal } = useConfirmModal({
title: "Submit application",
description:
"Are you sure you want to submit your Dub Network application for review? You won't be able to make changes to your application after submitting it.",
confirmText: "Confirm submission",
onConfirm: () => {
toast.success("Application submitted successfully");
},
});
+ if (!partner) return null;
+
return (📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if (!partner) return null; | |
| const { tasks, completedCount, totalCount, isComplete } = | |
| getNetworkProfileChecklistProgress({ | |
| partner, | |
| }); | |
| const [isExpanded, setIsExpanded] = useState(isComplete ? false : true); | |
| const { setShowConfirmModal, confirmModal } = useConfirmModal({ | |
| title: "Submit application", | |
| description: | |
| "Are you sure you want to submit your Dub Network application for review? You won't be able to make changes to your application after submitting it.", | |
| confirmText: "Confirm submission", | |
| onConfirm: () => { | |
| toast.success("Application submitted successfully"); | |
| }, | |
| }); | |
| const { tasks, completedCount, totalCount, isComplete } = partner | |
| ? getNetworkProfileChecklistProgress({ partner }) | |
| : { tasks: [], completedCount: 0, totalCount: 0, isComplete: false }; | |
| const [isExpanded, setIsExpanded] = useState(!isComplete); | |
| const { setShowConfirmModal, confirmModal } = useConfirmModal({ | |
| title: "Submit application", | |
| description: | |
| "Are you sure you want to submit your Dub Network application for review? You won't be able to make changes to your application after submitting it.", | |
| confirmText: "Confirm submission", | |
| onConfirm: () => { | |
| toast.success("Application submitted successfully"); | |
| }, | |
| }); | |
| if (!partner) return null; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@apps/web/app/`(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsx
around lines 21 - 38, Move all React hooks to the top of the component so they
run unconditionally: call useState (isExpanded, setIsExpanded) and
useConfirmModal (setShowConfirmModal, confirmModal) before the early return and
before invoking getNetworkProfileChecklistProgress. Keep the pure helper call
getNetworkProfileChecklistProgress guarded by a conditional/ternary that uses
partner ? getNetworkProfileChecklistProgress({ partner }) : { tasks: [],
completedCount: 0, totalCount: 0, isComplete: false } (or similar safe defaults)
so the rest of the render can use tasks/completedCount/totalCount/isComplete
without calling hooks conditionally. Ensure you still early-return null when
partner is absent if that’s required, but do not place any hook calls after that
return.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
apps/web/lib/actions/partners/update-partner-profile.ts (1)
62-73: ⚡ Quick winAttach the company-name refine error to the
companyNamefield.The cross-field
.refinehas nopath, so the error surfaces at the form root. The form readserrors.companyNameto render the inline error styling on the Legal company name input, so users won't see this message where it's expected.♻️ Proposed fix
.refine( (data) => { if (data.profileType === "company") { return !!data.companyName; } return true; }, { message: "Legal company name is required when profile type is 'company'.", + path: ["companyName"], }, );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/web/lib/actions/partners/update-partner-profile.ts` around lines 62 - 73, The cross-field zod .refine on the schema (used in update-partner-profile) currently validates that when data.profileType === "company" a companyName exists but has no path, so the error is attached to the form root; change the .refine call to include a path pointing to the companyName field (e.g., path: ["companyName"]) so the validation error is attached to errors.companyName and shows inline on the Legal company name input while keeping the same message and condition.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/web/app/`(ee)/admin.dub.co/(dashboard)/partners/trusted/page.tsx:
- Around line 502-506: The partner details card currently renders a raw <img>
with src={activePartner.image || ""} which can produce broken requests when
image is missing; replace that <img> block with the existing PartnerAvatar
component (use the same className, alt text from activePartner.name, and pass
activePartner.image as the image prop) so PartnerAvatar can provide the safe
fallback/no-src behavior instead of rendering an empty src; update the JSX in
the activePartner rendering area (replace the img element) to use <PartnerAvatar
image={activePartner.image} alt={activePartner.name} className="size-12 shrink-0
rounded-full border border-neutral-100 bg-neutral-100 object-cover" /> and
ensure PartnerAvatar is imported if not already.
In `@apps/web/lib/actions/partners/submit-network-profile.ts`:
- Around line 18-41: The current check uses the request-scoped
partner.networkStatus but then calls prisma.partner.update({ where: { id:
partner.id } }) which can overwrite a concurrent change; make the status
transition atomic by including the expected status in the update predicate and
checking the result. Replace the plain update with an updateMany (or update with
a compound where) that includes where: { id: partner.id, networkStatus: 'draft'
} and set data: { networkStatus: 'submitted', changeHistoryLog:
partnerChangeHistoryLog }; then verify the affected count (or catch a
not-found/no-rows-affected) and throw an error if no row was updated so you
don’t overwrite concurrent transitions. Ensure you still build
partnerChangeHistoryLog before the update and reference partner.networkStatus,
partnerChangeHistoryLog, and prisma.partner.update/updateMany in the fix.
In `@apps/web/lib/actions/partners/update-partner-profile.ts`:
- Around line 34-50: The username validation currently runs reserved-slug and
async reserved-username checks on every save and can reject unchanged usernames;
modify the logic so those checks are skipped when the submitted username equals
the stored partner username: move the reserved-slug/RESERVED_SLUGS,
validSlugRegex and isReservedUsername() checks out of the zod refine or
short-circuit them, and instead run them inside updatePartnerProfileAction only
when username is provided and username !== partner.username (i.e., guard the
validity checks and the uniqueness check so they execute only for a changed
username), ensuring existing partners with unchanged reserved usernames can
still update their profiles.
---
Nitpick comments:
In `@apps/web/lib/actions/partners/update-partner-profile.ts`:
- Around line 62-73: The cross-field zod .refine on the schema (used in
update-partner-profile) currently validates that when data.profileType ===
"company" a companyName exists but has no path, so the error is attached to the
form root; change the .refine call to include a path pointing to the companyName
field (e.g., path: ["companyName"]) so the validation error is attached to
errors.companyName and shows inline on the Legal company name input while
keeping the same message and condition.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: fbd52dd5-8e40-4fab-a097-2c83cb1724c7
📒 Files selected for processing (23)
apps/web/app/(ee)/admin.dub.co/(dashboard)/layout-nav-client.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/fraud/page.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/fraud/review-fraud-alert-sheet.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/layout.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/network/page.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/page.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/partners-nav-tabs.tsxapps/web/app/(ee)/admin.dub.co/(dashboard)/partners/trusted/page.tsxapps/web/app/(ee)/api/admin/fraud-alerts/route.tsapps/web/app/(ee)/api/admin/partners/[partnerId]/platforms/route.tsapps/web/app/(ee)/api/admin/partners/[partnerId]/route.tsapps/web/app/(ee)/api/admin/partners/fraud/route.tsapps/web/app/(ee)/api/admin/partners/network/route.tsapps/web/app/(ee)/api/admin/partners/route.tsapps/web/app/(ee)/api/admin/partners/trusted/route.tsapps/web/app/(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsxapps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsxapps/web/lib/actions/partners/submit-network-profile.tsapps/web/lib/actions/partners/update-partner-profile.tsapps/web/lib/zod/schemas/partner-profile.tsapps/web/lib/zod/schemas/workspaces.tsapps/web/ui/partners/partner-avatar.tsxpackages/utils/src/constants/reserved-slugs.ts
💤 Files with no reviewable changes (1)
- apps/web/app/(ee)/admin.dub.co/(dashboard)/layout-nav-client.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/network-approval-guide.tsx
Comment on lines
+502
to
+506
| <img | ||
| src={activePartner.image || ""} | ||
| alt={activePartner.name} | ||
| className="size-12 shrink-0 rounded-full border border-neutral-100 bg-neutral-100 object-cover" | ||
| /> |
Contributor
There was a problem hiding this comment.
Avoid rendering an empty image src in the partner details card.
On Line 503, src={activePartner.image || ""} can render a broken image and trigger avoidable requests when image is missing. Reuse PartnerAvatar here for a safe fallback.
Suggested fix
- <div className="flex items-start gap-3">
- <img
- src={activePartner.image || ""}
- alt={activePartner.name}
- className="size-12 shrink-0 rounded-full border border-neutral-100 bg-neutral-100 object-cover"
- />
+ <div className="flex items-start gap-3">
+ <PartnerAvatar
+ partner={{
+ id: activePartner.id,
+ name: activePartner.name,
+ image: activePartner.image,
+ }}
+ className="size-12 shrink-0 border border-neutral-100 bg-neutral-100 object-cover"
+ />
<div className="min-w-0">📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <img | |
| src={activePartner.image || ""} | |
| alt={activePartner.name} | |
| className="size-12 shrink-0 rounded-full border border-neutral-100 bg-neutral-100 object-cover" | |
| /> | |
| <div className="flex items-start gap-3"> | |
| <PartnerAvatar | |
| partner={{ | |
| id: activePartner.id, | |
| name: activePartner.name, | |
| image: activePartner.image, | |
| }} | |
| className="size-12 shrink-0 border border-neutral-100 bg-neutral-100 object-cover" | |
| /> | |
| <div className="min-w-0"> |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/web/app/`(ee)/admin.dub.co/(dashboard)/partners/trusted/page.tsx around
lines 502 - 506, The partner details card currently renders a raw <img> with
src={activePartner.image || ""} which can produce broken requests when image is
missing; replace that <img> block with the existing PartnerAvatar component (use
the same className, alt text from activePartner.name, and pass
activePartner.image as the image prop) so PartnerAvatar can provide the safe
fallback/no-src behavior instead of rendering an empty src; update the JSX in
the activePartner rendering area (replace the img element) to use <PartnerAvatar
image={activePartner.image} alt={activePartner.name} className="size-12 shrink-0
rounded-full border border-neutral-100 bg-neutral-100 object-cover" /> and
ensure PartnerAvatar is imported if not already.
Comment on lines
+18
to
+41
| if (partner.networkStatus !== "draft") { | ||
| throw new Error("Partner network profile not in 'draft' status"); | ||
| } | ||
|
|
||
| const partnerChangeHistoryLog = partner.changeHistoryLog | ||
| ? partnerProfileChangeHistoryLogSchema.parse(partner.changeHistoryLog) | ||
| : []; | ||
|
|
||
| partnerChangeHistoryLog.push({ | ||
| field: "networkStatus", | ||
| from: partner.networkStatus, | ||
| to: "submitted", | ||
| changedAt: new Date(), | ||
| }); | ||
|
|
||
| await prisma.partner.update({ | ||
| where: { | ||
| id: partner.id, | ||
| }, | ||
| data: { | ||
| networkStatus: "submitted", | ||
| changeHistoryLog: partnerChangeHistoryLog, | ||
| }, | ||
| }); |
Contributor
There was a problem hiding this comment.
Guard the status transition at write time.
Line 18 validates networkStatus on the request-scoped partner, but Line 33 updates by id only. A concurrent approval/rejection or profile update in between can be overwritten back to "submitted", along with a stale changeHistoryLog.
Suggested fix
- if (partner.networkStatus !== "draft") {
- throw new Error("Partner network profile not in 'draft' status");
- }
-
- const partnerChangeHistoryLog = partner.changeHistoryLog
- ? partnerProfileChangeHistoryLogSchema.parse(partner.changeHistoryLog)
- : [];
-
- partnerChangeHistoryLog.push({
- field: "networkStatus",
- from: partner.networkStatus,
- to: "submitted",
- changedAt: new Date(),
- });
-
- await prisma.partner.update({
- where: {
- id: partner.id,
- },
- data: {
- networkStatus: "submitted",
- changeHistoryLog: partnerChangeHistoryLog,
- },
- });
+ await prisma.$transaction(async (tx) => {
+ const freshPartner = await tx.partner.findUnique({
+ where: { id: partner.id },
+ select: {
+ networkStatus: true,
+ changeHistoryLog: true,
+ },
+ });
+
+ if (!freshPartner || freshPartner.networkStatus !== "draft") {
+ throw new Error("Partner network profile not in 'draft' status");
+ }
+
+ const partnerChangeHistoryLog = freshPartner.changeHistoryLog
+ ? partnerProfileChangeHistoryLogSchema.parse(
+ freshPartner.changeHistoryLog,
+ )
+ : [];
+
+ partnerChangeHistoryLog.push({
+ field: "networkStatus",
+ from: freshPartner.networkStatus,
+ to: "submitted",
+ changedAt: new Date(),
+ });
+
+ await tx.partner.update({
+ where: { id: partner.id },
+ data: {
+ networkStatus: "submitted",
+ changeHistoryLog: partnerChangeHistoryLog,
+ },
+ });
+ });📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if (partner.networkStatus !== "draft") { | |
| throw new Error("Partner network profile not in 'draft' status"); | |
| } | |
| const partnerChangeHistoryLog = partner.changeHistoryLog | |
| ? partnerProfileChangeHistoryLogSchema.parse(partner.changeHistoryLog) | |
| : []; | |
| partnerChangeHistoryLog.push({ | |
| field: "networkStatus", | |
| from: partner.networkStatus, | |
| to: "submitted", | |
| changedAt: new Date(), | |
| }); | |
| await prisma.partner.update({ | |
| where: { | |
| id: partner.id, | |
| }, | |
| data: { | |
| networkStatus: "submitted", | |
| changeHistoryLog: partnerChangeHistoryLog, | |
| }, | |
| }); | |
| await prisma.$transaction(async (tx) => { | |
| const freshPartner = await tx.partner.findUnique({ | |
| where: { id: partner.id }, | |
| select: { | |
| networkStatus: true, | |
| changeHistoryLog: true, | |
| }, | |
| }); | |
| if (!freshPartner || freshPartner.networkStatus !== "draft") { | |
| throw new Error("Partner network profile not in 'draft' status"); | |
| } | |
| const partnerChangeHistoryLog = freshPartner.changeHistoryLog | |
| ? partnerProfileChangeHistoryLogSchema.parse( | |
| freshPartner.changeHistoryLog, | |
| ) | |
| : []; | |
| partnerChangeHistoryLog.push({ | |
| field: "networkStatus", | |
| from: freshPartner.networkStatus, | |
| to: "submitted", | |
| changedAt: new Date(), | |
| }); | |
| await tx.partner.update({ | |
| where: { id: partner.id }, | |
| data: { | |
| networkStatus: "submitted", | |
| changeHistoryLog: partnerChangeHistoryLog, | |
| }, | |
| }); | |
| }); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/web/lib/actions/partners/submit-network-profile.ts` around lines 18 -
41, The current check uses the request-scoped partner.networkStatus but then
calls prisma.partner.update({ where: { id: partner.id } }) which can overwrite a
concurrent change; make the status transition atomic by including the expected
status in the update predicate and checking the result. Replace the plain update
with an updateMany (or update with a compound where) that includes where: { id:
partner.id, networkStatus: 'draft' } and set data: { networkStatus: 'submitted',
changeHistoryLog: partnerChangeHistoryLog }; then verify the affected count (or
catch a not-found/no-rows-affected) and throw an error if no row was updated so
you don’t overwrite concurrent transitions. Ensure you still build
partnerChangeHistoryLog before the update and reference partner.networkStatus,
partnerChangeHistoryLog, and prisma.partner.update/updateMany in the fix.
Comment on lines
+34
to
+50
| username: z | ||
| .string() | ||
| .trim() | ||
| .toLowerCase() | ||
| .min(3) | ||
| .max(100) | ||
| .refine( | ||
| async (v) => { | ||
| if (!v) return true; | ||
| if (!validSlugRegex.test(v) || RESERVED_SLUGS.includes(v)) | ||
| return false; | ||
| if (await isReservedUsername(v)) return false; | ||
| return true; | ||
| }, | ||
| { message: "Invalid username" }, | ||
| ) | ||
| .optional(), |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm whether any partners currently have a username that is now reserved
# (and therefore would be locked out by this validation).
rg -nP --type=ts -C2 'RESERVED_SLUGS\s*=\s*\['
rg -nP --type=ts -C2 '\bisReservedUsername\s*\('
rg -nP --type=ts -C3 '\bpartner\.username\b'Repository: dubinc/dub
Length of output: 4447
🏁 Script executed:
#!/bin/bash
# Get the complete update-partner-profile.ts file
wc -l apps/web/lib/actions/partners/update-partner-profile.tsRepository: dubinc/dub
Length of output: 114
🏁 Script executed:
#!/bin/bash
# Read the full update-partner-profile.ts file
cat -n apps/web/lib/actions/partners/update-partner-profile.tsRepository: dubinc/dub
Length of output: 10561
🏁 Script executed:
#!/bin/bash
# Check the profile form to understand form field handling
rg -nP --type=ts -A10 -B5 'data\.username.*\|\|' apps/web/components/partners/profile-details-form.tsxRepository: dubinc/dub
Length of output: 148
🏁 Script executed:
#!/bin/bash
# Find the profile details form
fd -type f -name '*profile*form*' apps/web/Repository: dubinc/dub
Length of output: 225
🏁 Script executed:
#!/bin/bash
# Also search for any form files that might handle partner profile
fd -type f -name '*details*form*' apps/web/components/partners/Repository: dubinc/dub
Length of output: 225
🏁 Script executed:
#!/bin/bash
# Find the profile details form
fd -name '*profile*form*' apps/web/Repository: dubinc/dub
Length of output: 285
🏁 Script executed:
#!/bin/bash
# Search for any form-related files in partners components
fd -name '*form*' apps/web/components/partners/Repository: dubinc/dub
Length of output: 285
🏁 Script executed:
#!/bin/bash
# Search for references to updatePartnerProfileAction
rg -l 'updatePartnerProfileAction' apps/web/Repository: dubinc/dub
Length of output: 338
🏁 Script executed:
#!/bin/bash
# Read the profile-details-form.tsx file
wc -l apps/web/app/\(ee\)/partners.dub.co/\(dashboard\)/profile/profile-details-form.tsxRepository: dubinc/dub
Length of output: 137
🏁 Script executed:
#!/bin/bash
# Read the profile-details-form.tsx file
cat -n "apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx"Repository: dubinc/dub
Length of output: 21515
Reserved-username check runs on every profile save and can lock out existing partners.
The schema validation (lines 34-50) checks username against validSlugRegex, RESERVED_SLUGS, and the async isReservedUsername() on every form submission. Since the username field is commented out in the form (profile-details-form.tsx lines 345-367) and the form always re-submits data.username || undefined from the stored partner username, any existing partner whose username is now in RESERVED_SLUGS becomes unable to update their profile.
For example, this PR adds "dub" to RESERVED_SLUGS, so any partner with partner.username === "dub" will fail schema validation when saving any profile changes—but they cannot edit the username field to fix it.
The check at line 119 only validates for duplicate usernames; it does not prevent the reserved-slug/reserved-username validation from blocking the request. Skip these checks when the value matches the stored username.
🛡️ Proposed fix (action layer)
- username: z
- .string()
- .trim()
- .toLowerCase()
- .min(3)
- .max(100)
- .refine(
- async (v) => {
- if (!v) return true;
- if (!validSlugRegex.test(v) || RESERVED_SLUGS.includes(v))
- return false;
- if (await isReservedUsername(v)) return false;
- return true;
- },
- { message: "Invalid username" },
- )
- .optional(),
+ username: z.string().trim().toLowerCase().min(3).max(100).optional(),Then validate inside updatePartnerProfileAction only when username && username !== partner.username:
if (username && username !== partner.username) {
if (!validSlugRegex.test(username) || RESERVED_SLUGS.includes(username)) {
throw new Error("Invalid username");
}
if (await isReservedUsername(username)) {
throw new Error("Invalid username");
}
// ...existing uniqueness check
}Side notes: The if (!v) return true branch is unreachable because .min(3) runs before the refine; and the single "Invalid username" message conflates three distinct failure modes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/web/lib/actions/partners/update-partner-profile.ts` around lines 34 -
50, The username validation currently runs reserved-slug and async
reserved-username checks on every save and can reject unchanged usernames;
modify the logic so those checks are skipped when the submitted username equals
the stored partner username: move the reserved-slug/RESERVED_SLUGS,
validSlugRegex and isReservedUsername() checks out of the zod refine or
short-circuit them, and instead run them inside updatePartnerProfileAction only
when username is provided and username !== partner.username (i.e., guard the
validity checks and the uniqueness check so they execute only for a changed
username), ensuring existing partners with unchanged reserved usernames can
still update their profiles.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@apps/web/app/`(ee)/partners.dub.co/(dashboard)/programs/marketplace/[programSlug]/header-controls.tsx:
- Around line 101-104: The onConfirm handler currently awaits
submitNetworkProfileAction() directly so thrown errors are hidden by
next-safe-action; wrap submitNetworkProfileAction with useAction (as done in
network-approval-guide.tsx) and call that wrapper inside onConfirm, providing
onSuccess to call mutate() and onError to handle/report the error (and prevent
mutate on failure); update the handler to use the returned action runner from
useAction for submitNetworkProfileAction and wire onSuccess/onError callbacks to
keep UI state consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a5574464-8339-4921-99be-a0c7af10e411
📒 Files selected for processing (2)
apps/web/app/(ee)/partners.dub.co/(dashboard)/programs/marketplace/[programSlug]/header-controls.tsxapps/web/lib/actions/partners/submit-network-profile.ts
Comment on lines
+101
to
+104
| onConfirm: async () => { | ||
| await submitNetworkProfileAction(); | ||
| await mutate(); | ||
| }, |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify next-safe-action usage patterns in the codebase to confirm error handling conventions
# Check how other actions handle results and errors
rg -n -A5 -B2 'executeAsync|\.action\(' --type=ts --type=tsx -g '!node_modules' | head -80Repository: dubinc/dub
Length of output: 82
🏁 Script executed:
#!/bin/bash
# Find the specific file and examine the context
find . -type f -name "header-controls.tsx" -path "*programs/marketplace*"Repository: dubinc/dub
Length of output: 157
🏁 Script executed:
#!/bin/bash
# Search for action usage patterns with corrected file type flag
rg -n -A5 -B2 'executeAsync|\.action\(' --type=ts -g '!node_modules' | head -100Repository: dubinc/dub
Length of output: 7860
🏁 Script executed:
#!/bin/bash
# Search for submitNetworkProfileAction definition
rg -n 'submitNetworkProfileAction' --type=ts --type=js -g '!node_modules'Repository: dubinc/dub
Length of output: 820
🏁 Script executed:
#!/bin/bash
# Examine the header-controls.tsx file around the problematic lines
cat -n apps/web/app/\(ee\)/partners.dub.co/\(dashboard\)/programs/marketplace/\[programSlug\]/header-controls.tsx | sed -n '90,115p'Repository: dubinc/dub
Length of output: 1004
🏁 Script executed:
#!/bin/bash
# Examine the submitNetworkProfileAction definition
cat -n apps/web/lib/actions/partners/submit-network-profile.tsRepository: dubinc/dub
Length of output: 2734
🏁 Script executed:
#!/bin/bash
# Examine how it's used in network-approval-guide.tsx
cat -n apps/web/app/\(ee\)/partners.dub.co/\(dashboard\)/profile/network-approval-guide.tsx | sed -n '40,70p'Repository: dubinc/dub
Length of output: 1183
🏁 Script executed:
#!/bin/bash
# Look for how other actions handle results in callbacks/executeAsync
rg -n -A10 'executeAsync.*await' --type=ts -g '!node_modules' | head -150Repository: dubinc/dub
Length of output: 36
🏁 Script executed:
#!/bin/bash
# Check if header-controls.tsx imports useAction and what other imports it has
head -30 apps/web/app/\(ee\)/partners.dub.co/\(dashboard\)/programs/marketplace/\[programSlug\]/header-controls.tsxRepository: dubinc/dub
Length of output: 1341
🏁 Script executed:
#!/bin/bash
# Look for useAction hook definition/import patterns
rg -n 'from.*useAction|export.*useAction' --type=ts -g '!node_modules' | head -20Repository: dubinc/dub
Length of output: 36
Wrap submitNetworkProfileAction with useAction to properly handle errors.
The onConfirm handler calls submitNetworkProfileAction() directly without error handling. Since next-safe-action wraps thrown errors into the result object (rather than rejecting), direct awaits won't throw—errors will be silent and mutate() will execute regardless, leaving the UI inconsistent.
The same action is properly handled in network-approval-guide.tsx (lines 47-56) using useAction with onSuccess and onError callbacks. Apply that pattern here:
Suggested approach
Replace the direct call with useAction wrapper:
+ const { executeAsync: submitNetworkProfile } = useAction(
+ submitNetworkProfileAction,
+ {
+ onSuccess: () => {
+ toast.success("Application submitted successfully!");
+ },
+ onError: ({ error }) => {
+ toast.error(error.serverError);
+ },
+ },
+ );
+
const { setShowConfirmModal, confirmModal } = useConfirmModal({
title: "Submit application",
description:
"Are you sure you want to submit your Dub Network application for review? You won't be able to make changes to your application after submitting it.",
confirmText: "Confirm submission",
onConfirm: async () => {
- await submitNetworkProfileAction();
+ await submitNetworkProfile();
await mutate();
},
});🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@apps/web/app/`(ee)/partners.dub.co/(dashboard)/programs/marketplace/[programSlug]/header-controls.tsx
around lines 101 - 104, The onConfirm handler currently awaits
submitNetworkProfileAction() directly so thrown errors are hidden by
next-safe-action; wrap submitNetworkProfileAction with useAction (as done in
network-approval-guide.tsx) and call that wrapper inside onConfirm, providing
onSuccess to call mutate() and onError to handle/report the error (and prevent
mutate on failure); update the handler to use the returned action runner from
useAction for submitNetworkProfileAction and wire onSuccess/onError callbacks to
keep UI state consistent.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Refactor
Style
Other