Remove old columns #3133
Remove old columns #3133
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughThe PR removes deprecated schema fields and updates TypeScript directives in migration scripts. Specifically: two calculated stats fields (leadConversionRate, conversionRate) are deleted from the ProgramEnrollment model, the amount field is removed from the Reward model, and TypeScript nocheck comments are added/updated in migration scripts. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/scripts/migrations/migrate-reward-amounts.ts (1)
35-90: Consider adding error handling for robust migration execution.The script lacks try-catch blocks around the update operations (lines 78–87). If any reward update fails mid-batch, the script halts and the database is left in a partially migrated state, requiring manual re-run and potential duplicate-processing issues.
Consider wrapping the update in a try-catch block to log errors and optionally continue with the next reward, or wrap the entire loop in error handling to make re-runs safer.
for (const reward of rewards) { try { const amount = reward.amount ?? 0; // ... migration logic ... await prisma.reward.update({ where: { id: reward.id }, data: { amountInCents, amountInPercentage, modifiers: updatedModifiers ?? Prisma.DbNull, }, }); totalMigrated++; } catch (error) { console.error(`Failed to migrate reward ${reward.id}:`, error); // Decide: throw to halt, or continue to next reward throw error; } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
apps/web/scripts/migrations/migrate-reward-amounts.ts(1 hunks)apps/web/scripts/migrations/migrate-rewards-remainder.ts(1 hunks)packages/prisma/schema/program.prisma(0 hunks)packages/prisma/schema/reward.prisma(0 hunks)
💤 Files with no reviewable changes (2)
- packages/prisma/schema/reward.prisma
- packages/prisma/schema/program.prisma
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: TWilson023
Repo: dubinc/dub PR: 2935
File: packages/prisma/schema/workspace.prisma:21-36
Timestamp: 2025-10-06T15:48:45.956Z
Learning: In the Dub repository (dubinc/dub), Prisma schema changes are not managed with separate migration files. Do not flag missing Prisma migration files when schema changes are made to files like `packages/prisma/schema/workspace.prisma` or other schema files.
📚 Learning: 2025-10-06T15:48:45.956Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 2935
File: packages/prisma/schema/workspace.prisma:21-36
Timestamp: 2025-10-06T15:48:45.956Z
Learning: In the Dub repository (dubinc/dub), Prisma schema changes are not managed with separate migration files. Do not flag missing Prisma migration files when schema changes are made to files like `packages/prisma/schema/workspace.prisma` or other schema files.
Applied to files:
apps/web/scripts/migrations/migrate-rewards-remainder.ts
📚 Learning: 2025-09-24T16:13:00.387Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: packages/prisma/schema/partner.prisma:151-153
Timestamp: 2025-09-24T16:13:00.387Z
Learning: In the Dub codebase, Prisma schemas use single-column indexes without brackets (e.g., `@index(partnerId)`) and multi-column indexes with brackets (e.g., `@index([programId, partnerId])`). This syntax pattern is consistently used throughout their schema files and works correctly with their Prisma version.
Applied to files:
apps/web/scripts/migrations/migrate-rewards-remainder.ts
📚 Learning: 2025-09-12T17:31:10.548Z
Learnt from: devkiran
Repo: dubinc/dub PR: 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).
Applied to files:
apps/web/scripts/migrations/migrate-reward-amounts.ts
📚 Learning: 2025-07-30T15:25:13.936Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 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.
Applied to files:
apps/web/scripts/migrations/migrate-reward-amounts.ts
📚 Learning: 2025-07-30T15:29:54.131Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 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.
Applied to files:
apps/web/scripts/migrations/migrate-reward-amounts.ts
📚 Learning: 2025-08-14T05:17:51.825Z
Learnt from: devkiran
Repo: dubinc/dub PR: 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.
Applied to files:
apps/web/scripts/migrations/migrate-reward-amounts.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (4)
apps/web/scripts/migrations/migrate-reward-amounts.ts (3)
1-6: Verify deployment order: migration script must run before schema changes.The script queries and selects the
amountfield (line 21), which is being removed from the Reward schema. Ensure this migration script runs against the database before the Prisma schema is updated to remove theamountcolumn.
36-45: Verify that defaulting null amounts to 0 is intentional.Line 36 defaults
reward.amount ?? 0, so rewards withnullorundefinedamounts will be migrated as zero-valued rewards. Ensure this behavior matches business intent—otherwise, consider throwing an error to flag unexpected missing amounts.
47-72: Type migration and modifier fallback logic is sound.The script correctly maps old
amountto new fields based on reward type, and applies sensible fallback logic: if a modifier lacks a type, it inherits the parent reward's type (line 64). ThePrisma.DbNullusage (line 85) is correct for setting modifiers to NULL when undefined.apps/web/scripts/migrations/migrate-rewards-remainder.ts (1)
1-1: Documentation update is clear and consistent.The @ts-nocheck comment now accurately describes the purpose—that the script contains old schema code. This aligns with the pattern established in
migrate-reward-amounts.tsand improves maintainability for future readers.
Summary by CodeRabbit
Refactor
Chores