Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@steven-tey
Copy link
Collaborator

@steven-tey steven-tey commented Jul 31, 2025

Summary by CodeRabbit

  • New Features

    • Rewards in the earnings calculator are now automatically sorted by event priority ("sale", "lead", "click") for more accurate calculations.
  • Style

    • Updated the slider label in the earnings calculator from "Customer sales" to "Customer referrals".
  • Refactor

    • Improved naming consistency for bulk partner approval and rejection actions and schemas.
    • Enhanced reward sorting logic to allow custom event order and stronger typing.

@vercel
Copy link
Contributor

vercel bot commented Jul 31, 2025

The latest updates on your projects. Learn more about Vercel for Git β†—οΈŽ

Name Status Preview Updated (UTC)
dub βœ… Ready (Inspect) Visit Preview Jul 31, 2025 4:51pm

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jul 31, 2025

Walkthrough

This update standardizes schema and action naming conventions for bulk partner approval and rejection throughout the codebase. It also enhances reward sorting by introducing a flexible, type-safe event order and applies this sorting in the earnings calculator. Additionally, a UI label is updated for clarity.

Changes

Cohort / File(s) Change Summary
Bulk Partner Actions & Schemas Renaming
apps/web/lib/actions/partners/bulk-approve-partners.ts, apps/web/lib/actions/partners/bulk-reject-partners.ts, apps/web/lib/zod/schemas/partners.ts, apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx
Renamed bulk partner approval and rejection schemas and actions for consistency:
- approvePartnersBulkSchema β†’ bulkApprovePartnersSchema
- rejectPartnersBulkSchema β†’ bulkRejectPartnersSchema
- rejectPartnersBulkAction β†’ bulkRejectPartnersAction
Updated imports and usages accordingly.
Reward Sorting Logic Enhancement
apps/web/lib/partners/sort-rewards-by-event-order.ts
Replaced hardcoded event string array with a type-safe, enum-based event order. Updated the sorting function to accept an optional custom event order, improving flexibility and type safety.
UI Reward Sorting & Label Update
apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx
Rewards are now sorted by event order ("sale", "lead", "click") before selection. The slider label text is updated from "Customer sales" to "Customer referrals".

Sequence Diagram(s)

sequenceDiagram
    participant UI as EarningsCalculatorBlock
    participant Sorter as sortRewardsByEventOrder

    UI->>Sorter: sortRewardsByEventOrder(rewards, ["sale", "lead", "click"])
    Sorter-->>UI: sortedRewards
    UI->>UI: Use sortedRewards[0] for calculations
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

In fields of code where partners play,
Names align and schemas sway.
Rewards now sorted, clear and neat,
"Referrals" makes the label sweet.
With every hop, the logic's tightβ€”
This bunny’s proud: the code feels right! πŸ‡βœ¨

Note

⚑️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.


πŸ“œ Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

πŸ“₯ Commits

Reviewing files that changed from the base of the PR and between a15b6d6 and f93daee.

πŸ“’ Files selected for processing (6)
  • apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx (2 hunks)
  • apps/web/lib/actions/partners/bulk-approve-partners.ts (1 hunks)
  • apps/web/lib/actions/partners/bulk-reject-partners.ts (1 hunks)
  • apps/web/lib/partners/sort-rewards-by-event-order.ts (1 hunks)
  • apps/web/lib/zod/schemas/partners.ts (2 hunks)
  • apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx (3 hunks)
🧰 Additional context used
🧠 Learnings (7)
πŸ““ Common learnings
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#2635
File: packages/prisma/schema/payout.prisma:24-25
Timestamp: 2025-07-11T16:28:55.693Z
Learning: In the Dub codebase, multiple payout records can now share the same stripeTransferId because payouts are grouped by partner and processed as single Stripe transfers. This is why the @unique constraint was removed from the stripeTransferId field in the Payout model - a single transfer can include multiple payouts for the same partner.
πŸ“š Learning: in apps/web/ui/partners/rewards/add-edit-reward-sheet.tsx, the form schema uses partial condition ob...
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.

Applied to files:

  • apps/web/lib/actions/partners/bulk-approve-partners.ts
  • apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx
  • apps/web/lib/actions/partners/bulk-reject-partners.ts
  • apps/web/lib/zod/schemas/partners.ts
  • apps/web/lib/partners/sort-rewards-by-event-order.ts
πŸ“š Learning: in apps/web/ui/partners/rewards/rewards-logic.tsx, when setting the entity field in a reward conditi...
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.

Applied to files:

  • apps/web/lib/actions/partners/bulk-approve-partners.ts
  • apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx
  • apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx
  • apps/web/lib/actions/partners/bulk-reject-partners.ts
  • apps/web/lib/zod/schemas/partners.ts
  • apps/web/lib/partners/sort-rewards-by-event-order.ts
πŸ“š Learning: in apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined res...
Learnt from: devkiran
PR: dubinc/dub#2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.

Applied to files:

  • apps/web/lib/actions/partners/bulk-approve-partners.ts
  • apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx
  • apps/web/lib/actions/partners/bulk-reject-partners.ts
  • apps/web/lib/zod/schemas/partners.ts
πŸ“š Learning: in the singular integration (apps/web/app/(ee)/api/singular/webhook/route.ts), the event names in th...
Learnt from: devkiran
PR: dubinc/dub#2637
File: apps/web/app/(ee)/api/singular/webhook/route.ts:0-0
Timestamp: 2025-07-17T06:41:45.620Z
Learning: In the Singular integration (apps/web/app/(ee)/api/singular/webhook/route.ts), the event names in the singularToDubEvent object have intentionally different casing: "Copy GAID" and "copy IDFA". This casing difference is valid and should not be changed, as these are the correct event names expected from Singular.

Applied to files:

  • apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx
  • apps/web/lib/zod/schemas/partners.ts
  • apps/web/lib/partners/sort-rewards-by-event-order.ts
πŸ“š Learning: in apps/web/ui/partners/design/previews/lander-preview.tsx, the ellipsis wave animation delay calcul...
Learnt from: TWilson023
PR: dubinc/dub#2614
File: apps/web/ui/partners/design/previews/lander-preview.tsx:181-181
Timestamp: 2025-07-09T20:52:56.592Z
Learning: In apps/web/ui/partners/design/previews/lander-preview.tsx, the ellipsis wave animation delay calculation `3 - i * -0.15` is intentionally designed to create negative delays that offset each dot's animation cycle. This pattern works correctly for the intended ellipsis effect and should not be changed to positive incremental delays.

Applied to files:

  • apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx
πŸ“š Learning: in the partnerprogramsummary email template (packages/email/src/templates/partner-program-summary.ts...
Learnt from: devkiran
PR: dubinc/dub#2448
File: packages/email/src/templates/partner-program-summary.tsx:0-0
Timestamp: 2025-05-29T04:45:18.504Z
Learning: In the PartnerProgramSummary email template (packages/email/src/templates/partner-program-summary.tsx), the stat titles are hardcoded constants ("Clicks", "Leads", "Sales", "Earnings") that will always match the ICONS object keys after toLowerCase() conversion, so icon lookup failures are not possible.

Applied to files:

  • apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx
  • apps/web/lib/partners/sort-rewards-by-event-order.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 (11)
apps/web/lib/zod/schemas/partners.ts (1)

536-543: LGTM: Consistent naming convention improvements

The schema renaming from approvePartnersBulkSchema/rejectPartnersBulkSchema to bulkApprovePartnersSchema/bulkRejectPartnersSchema follows a consistent bulk[Action][Entity]Schema pattern. The internal validation logic remains unchanged, preserving the existing functionality while improving naming consistency.

Also applies to: 550-557

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx (1)

4-4: LGTM: Import and usage properly updated

The import and useAction usage have been correctly updated to match the renamed bulkRejectPartnersAction. The changes maintain consistency with the schema renaming and preserve all existing functionality.

Also applies to: 91-91

apps/web/lib/actions/partners/bulk-approve-partners.ts (1)

6-6: LGTM: Schema import and usage properly updated

The import and schema usage have been correctly updated to reference the renamed bulkApprovePartnersSchema. The changes maintain consistency with the naming convention improvements while preserving all existing functionality.

Also applies to: 14-14

apps/web/lib/actions/partners/bulk-reject-partners.ts (1)

5-5: LGTM: Complete naming convention alignment

All three aspects have been properly updated:

  • Import of the renamed schema
  • Export of the renamed action
  • Schema usage in the action definition

The changes maintain full consistency with the naming convention standardization while preserving all existing functionality.

Also applies to: 12-13

apps/web/lib/partners/sort-rewards-by-event-order.ts (4)

1-1: LGTM!

The addition of EventType to the import statement properly supports the transition from hardcoded strings to typed enum values.


3-7: LGTM!

The typed constant definition improves type safety while maintaining the same event order. The as const assertion ensures proper literal type inference.


11-11: LGTM!

The optional parameter with sophisticated typing (typeof DEFAULT_REWARD_EVENT_ORDER)[number][] correctly constrains the custom event order to valid EventType values while maintaining flexibility.


13-18: LGTM!

The implementation correctly handles both custom and default event orders. The type assertion is necessary and appropriate given the parameter constraints, and the dynamic eventOrderMap construction maintains the existing sorting logic while adding flexibility.

apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx (3)

4-4: LGTM!

The import addition is necessary for the new reward sorting functionality.


35-35: LGTM!

The reward sorting with custom order ["sale", "lead", "click"] prioritizes higher-value rewards for the earnings calculator, which provides a more compelling user experience while maintaining the existing logic pattern.


56-56: LGTM!

The label change from "Customer sales" to "Customer referrals" uses more accurate terminology that better reflects the partner's role in the referral process.

✨ Finishing Touches
  • πŸ“ Generate Docstrings
πŸ§ͺ Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix-reward-order

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.

❀️ Share
πŸͺ§ Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@steven-tey
Copy link
Collaborator Author

@CodeRabbit final review please

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jul 31, 2025

🧩 Analysis chain

I'll conduct a final review of the PR. Let me examine the changes to understand what was modified to fix the reward order.


🏁 Script executed:

#!/bin/bash
# Get the list of files changed in this PR
git diff --name-only HEAD~1 HEAD

# Get a summary of the changes
git diff --stat HEAD~1 HEAD

# Show the actual changes
git diff HEAD~1 HEAD

Length of output: 648


Let me try different approaches to examine the PR changes.


🏁 Script executed:

#!/bin/bash
# Try to get PR information using GitHub CLI
gh pr view 2699 --json files,title,body,commits

# Check git log for recent commits
git log --oneline -5

# Check current branch and status
git branch
git status

# Look for any recently modified files
find . -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" | head -20

Length of output: 2489


Perfect! I can see the PR changes now. Let me examine the key files to understand how the reward order was fixed.


🏁 Script executed:

#!/bin/bash
# Examine the main file that seems to handle reward sorting
cat "apps/web/lib/partners/sort-rewards-by-event-order.ts"

# Look at the partner applications page changes
cat "apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/applications/page-client.tsx"

# Check the bulk approve/reject changes
cat "apps/web/lib/actions/partners/bulk-approve-partners.ts"
cat "apps/web/lib/actions/partners/bulk-reject-partners.ts"

Length of output: 19763


Let me examine the remaining changed files to understand the complete picture.


🏁 Script executed:

#!/bin/bash
# Check the zod schema changes
cat "apps/web/lib/zod/schemas/partners.ts"

# Check the earnings calculator changes
cat "apps/web/ui/partners/lander/blocks/earnings-calculator-block.tsx"

# Let's also see if there are any imports or usages of the sort function
rg "sortRewardsByEventOrder" -A 2 -B 2

Length of output: 29236


@steven-tey I've completed my final review of the PR. This is an excellent implementation that properly addresses the reward order issue. Here's my comprehensive assessment:

βœ… Excellent Implementation

The changes demonstrate several strong engineering practices:

1. Well-Designed Core Function (sort-rewards-by-event-order.ts)

  • Performance optimized: Uses Map for O(1) event lookups instead of linear array searches
  • Immutable: Creates array copy with [...rewards] before sorting
  • Flexible: Accepts custom event orders while providing sensible defaults
  • Robust fallback: Uses MAX_SAFE_INTEGER for unmapped events
  • Type-safe: Proper generic typing with Pick<Reward, "event">

2. Consistent Integration
The sorting function is properly integrated across the codebase:

  • Earnings calculator: Uses custom order ["sale", "lead", "click"] to prioritize highest-value events
  • Program fetchers: Ensures consistent reward ordering in API responses
  • Partner management: Applied in bulk approve/reject workflows
  • Embed utilities: Maintains consistent ordering in embedded contexts

3. Code Quality

  • Clean, readable implementation
  • Proper separation of concerns
  • Consistent naming conventions
  • No performance bottlenecks or memory leaks

🎯 PR Objectives Met

The "Fix reward order" objective is fully accomplished with a scalable, maintainable solution that can be easily extended for future use cases.

The implementation handles edge cases well and provides a solid foundation for reward ordering throughout the application.

Recommendation: βœ… Approve and merge

     /|   /|  
    ( :v:  )
     |(_)|
     -"-"-
  Great work! πŸš€
βœ… Actions performed

Comments resolved.

@steven-tey steven-tey merged commit 568a813 into main Jul 31, 2025
9 checks passed
@steven-tey steven-tey deleted the fix-reward-order branch July 31, 2025 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants