Remove programEnrollment dependency on notify-partner/program #3099
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Rate limit exceeded@steven-tey has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 19 minutes and 13 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
WalkthroughRefactors two cron notification routes to fetch Changes
Sequence Diagram(s)sequenceDiagram
participant Cron
participant DB as Database
participant Email as Email Service
participant Log as Notification Log
rect rgb(220,220,255)
Note over Cron,DB: OLD flow (via programEnrollment)
Cron->>DB: findUniqueOrThrow(programEnrollment)
DB-->>Cron: programEnrollment { partner, program, workspace }
end
rect rgb(220,255,220)
Note over Cron,DB: NEW flow (direct parallel fetches)
Cron->>DB: Promise.all([findUnique(partnerId), findUnique(programId)])
DB-->>Cron: partner { messages, users }, program { messages, workspace, name }
end
rect rgb(255,245,220)
Note over Cron: Message filtering & payload build
Cron->>Cron: Filter messages (last 3 days, unread, sender checks)
Cron->>Cron: Build React payload & subject (uses program/partner)
end
Cron->>Email: sendEmail(recipient, subject, reactPayload)
Cron->>Log: createMany(NotificationEmail records per recipient)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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 full review |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/web/app/(ee)/api/cron/messages/notify-partner/route.ts (1)
120-128: Critical: Add null check before accessing senderUser properties.The code accesses
message.senderUser.namewithout first checking ifsenderUserexists. If the user was deleted or is missing, this will throw a TypeError.Apply this diff to add optional chaining:
- user: message.senderUser.name + user: message.senderUser?.name ? { name: message.senderUser.name, image: message.senderUser.image, } : { name: program.name, image: program.logo, },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/web/app/(ee)/api/cron/messages/notify-partner/route.ts(3 hunks)apps/web/app/(ee)/api/cron/messages/notify-program/route.ts(3 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-12T22:23:10.390Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 3098
File: apps/web/lib/actions/partners/message-program.ts:49-58
Timestamp: 2025-11-12T22:23:10.390Z
Learning: In apps/web/lib/actions/partners/message-program.ts, when checking if a partner can continue messaging after messaging is disabled, the code intentionally requires `senderPartnerId: null` (program-initiated messages) to prevent partners from continuing to send junk messages. Only conversations started by the program should continue after messaging is disabled, as a spam prevention mechanism.
Applied to files:
apps/web/app/(ee)/api/cron/messages/notify-partner/route.tsapps/web/app/(ee)/api/cron/messages/notify-program/route.ts
📚 Learning: 2025-09-17T17:44:03.965Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 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.
Applied to files:
apps/web/app/(ee)/api/cron/messages/notify-partner/route.tsapps/web/app/(ee)/api/cron/messages/notify-program/route.ts
🧬 Code graph analysis (2)
apps/web/app/(ee)/api/cron/messages/notify-partner/route.ts (1)
packages/prisma/index.ts (1)
prisma(3-9)
apps/web/app/(ee)/api/cron/messages/notify-program/route.ts (1)
packages/prisma/index.ts (1)
prisma(3-9)
⏰ 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 (1)
apps/web/app/(ee)/api/cron/messages/notify-partner/route.ts (1)
80-80: LGTM!The data extraction from the
partnerobject is straightforward and correct. TheunreadMessagesandpartnerUsersToNotifyare properly derived from the refactored query structure.Also applies to: 93-95
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/app/(ee)/api/cron/messages/notify-program/route.ts (1)
58-58: Consider removing unused senderPartner include.The
senderPartnerrelation is included but never used in the email template composition (lines 121-122 only usetextandcreatedAt). Removing this include would reduce unnecessary data fetching.Apply this diff to remove the unused include:
include: { - senderPartner: true, },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/web/app/(ee)/api/cron/messages/notify-partner/route.ts(2 hunks)apps/web/app/(ee)/api/cron/messages/notify-program/route.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/app/(ee)/api/cron/messages/notify-partner/route.ts
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-09-17T17:44:03.965Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 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.
Applied to files:
apps/web/app/(ee)/api/cron/messages/notify-program/route.ts
📚 Learning: 2025-11-12T22:23:10.390Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 3098
File: apps/web/lib/actions/partners/message-program.ts:49-58
Timestamp: 2025-11-12T22:23:10.390Z
Learning: In apps/web/lib/actions/partners/message-program.ts, when checking if a partner can continue messaging after messaging is disabled, the code intentionally requires `senderPartnerId: null` (program-initiated messages) to prevent partners from continuing to send junk messages. Only conversations started by the program should continue after messaging is disabled, as a spam prevention mechanism.
Applied to files:
apps/web/app/(ee)/api/cron/messages/notify-program/route.ts
🧬 Code graph analysis (1)
apps/web/app/(ee)/api/cron/messages/notify-program/route.ts (1)
packages/prisma/index.ts (1)
prisma(3-9)
⏰ 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 (3)
apps/web/app/(ee)/api/cron/messages/notify-program/route.ts (3)
36-82: LGTM! Clean refactoring with parallel data fetching.The refactoring successfully removes the programEnrollment dependency by fetching program and partner directly in parallel. The approach is more efficient and the data access patterns are clear. Using
findUniqueOrThrowprovides appropriate error handling that will be caught by the outer try-catch block.
93-96: LGTM! Effective duplicate prevention.The check ensures that only the most recent unread message triggers a notification, preventing duplicate emails if newer messages arrive between scheduling and execution.
109-125: LGTM! Well-implemented email composition.The dynamic subject line provides clear context about message count, and the message reversal ensures chronological display in the email (oldest to newest). The comment about
.toReversed()is helpful for future maintainers.
Summary by CodeRabbit