Exclude payouts from confirmation #2689
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis change introduces the ability to exclude specific payout IDs from payout confirmation and splitting processes. The exclusion logic is implemented across backend API handlers, action schemas, and UI components, allowing users to interactively include or exclude payouts from invoice calculations and confirmations. Supporting type and table rendering updates are also included. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI (payout-invoice-sheet.tsx)
participant Action (confirm-payouts.ts)
participant API Route (route.ts)
participant Backend (confirm-payouts.ts / split-payouts.ts)
User->>UI (payout-invoice-sheet.tsx): Exclude/Include payout(s)
UI->>Action (confirm-payouts.ts): Submit confirmation with excludedPayoutIds
Action->>API Route (route.ts): POST request with excludedPayoutIds
API Route->>Backend (split-payouts.ts): Call splitPayouts({..., excludedPayoutIds})
API Route->>Backend (confirm-payouts.ts): Call confirmPayouts({..., excludedPayoutIds})
Backend-->>API Route: Processed payouts (excluding specified IDs)
API Route-->>Action: Response
Action-->>UI: Confirmation result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Suggested reviewers
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ 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)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
apps/web/ui/partners/payout-invoice-sheet.tsx (1)
480-484: Missing integration: excludedPayoutIds not passed to backend action.The UI tracks excluded payouts but doesn't pass the
excludedPayoutIdsto theexecuteAsynccall, which means the exclusion feature won't work end-to-end.Apply this diff to pass the excluded payout IDs to the backend:
await executeAsync({ workspaceId, paymentMethodId: selectedPaymentMethod.id, cutoffPeriod, + excludedPayoutIds, });This ensures the excluded payouts are actually filtered out during the confirmation process.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts(3 hunks)apps/web/app/(ee)/api/cron/payouts/confirm/route.ts(4 hunks)apps/web/app/(ee)/api/cron/payouts/confirm/split-payouts.ts(2 hunks)apps/web/lib/actions/partners/confirm-payouts.ts(2 hunks)apps/web/ui/partners/payout-invoice-sheet.tsx(3 hunks)packages/ui/src/table/table.tsx(2 hunks)packages/ui/src/table/types.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.
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.
apps/web/lib/actions/partners/confirm-payouts.ts (2)
Learnt from: devkiran
PR: #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.
Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.
apps/web/ui/partners/payout-invoice-sheet.tsx (1)
Learnt from: devkiran
PR: #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.
apps/web/app/(ee)/api/cron/payouts/confirm/split-payouts.ts (2)
Learnt from: devkiran
PR: #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.
Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.
apps/web/app/(ee)/api/cron/payouts/confirm/route.ts (3)
Learnt from: devkiran
PR: #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.
Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.
Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-19T01:46:45.723Z
Learning: PayPal webhook verification in the Dub codebase is handled at the route level in apps/web/app/(ee)/api/paypal/webhook/route.ts using the verifySignature function. Individual webhook handlers like payoutsItemFailed don't need to re-verify signatures since they're only called after successful verification.
apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts (2)
Learnt from: devkiran
PR: #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.
Learnt from: steven-tey
PR: dubinc/dub#0
File: :0-0
Timestamp: 2025-06-25T21:20:59.837Z
Learning: In the Dub codebase, payout limit validation uses a two-stage pattern: server actions perform quick sanity checks (payoutsUsage > payoutsLimit) for immediate user feedback, while the cron job (/cron/payouts) performs authoritative validation (payoutsUsage + payoutAmount > payoutsLimit) with actual calculated amounts before processing. This design provides fast user feedback while ensuring accurate limit enforcement at transaction time.
⏰ 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 (18)
packages/ui/src/table/types.ts (1)
67-67: LGTM! Enhanced tdClassName function signature enables row-based styling.The updated signature allows the tdClassName function to access both column ID and row data, enabling more dynamic cell styling based on row state. This is essential for features like styling excluded payouts differently.
packages/ui/src/table/table.tsx (2)
247-249: LGTM! Correctly implements the enhanced tdClassName signature.The function call now passes both
cell.column.idandrowparameters, matching the updated type definition. The implementation maintains backward compatibility with string-based tdClassName.
489-491: LGTM! Consistent implementation across both rendering paths.Both the resizable and non-resizable table row rendering paths now correctly call tdClassName with the enhanced signature, ensuring consistent behavior.
apps/web/lib/actions/partners/confirm-payouts.ts (3)
16-16: LGTM! Properly extends schema for payout exclusion.The optional
excludedPayoutIdsparameter allows selective exclusion of payouts while maintaining backward compatibility with existing code that doesn't provide this parameter.
24-24: LGTM! Correctly extracts the exclusion parameter.The destructuring properly extracts the
excludedPayoutIdsfrom the validated input, following the established pattern in the codebase.
65-65: LGTM! Forwards exclusion parameter to background job.The
excludedPayoutIdsis correctly included in the qstash payload, ensuring the exclusion list propagates to the background processing job.apps/web/app/(ee)/api/cron/payouts/confirm/route.ts (4)
18-18: LGTM! Extends API schema for payout exclusion.The optional
excludedPayoutIdsparameter maintains backward compatibility while enabling the new exclusion functionality.
30-36: LGTM! Clean parameter extraction from request body.The destructuring cleanly extracts all parameters including the new
excludedPayoutIdsfrom the validated request payload.
54-54: LGTM! Forwards exclusion parameter to splitPayouts.The
excludedPayoutIdsis correctly passed to thesplitPayoutsfunction, enabling exclusion during the payout splitting process.
64-64: LGTM! Forwards exclusion parameter to confirmPayouts.The
excludedPayoutIdsis correctly passed to theconfirmPayoutsfunction, ensuring excluded payouts are not processed during confirmation.apps/web/app/(ee)/api/cron/payouts/confirm/split-payouts.ts (2)
13-13: LGTM! Properly extends function signature for exclusion.The optional
excludedPayoutIdsparameter enables selective exclusion of payouts while maintaining backward compatibility for existing callers.Also applies to: 17-17
35-35: LGTM! Correctly implements exclusion filter in database query.The conditional spread operator with
notInfilter properly excludes specified payout IDs from processing. The implementation only applies the filter whenexcludedPayoutIdsis provided, maintaining efficient queries when exclusion is not needed.apps/web/app/(ee)/api/cron/payouts/confirm/confirm-payouts.ts (2)
35-51: LGTM! Function signature properly updated for exclusion feature.The addition of the optional
excludedPayoutIdsparameter is well-typed and maintains backward compatibility.
83-83: LGTM! Exclusion logic correctly implemented.The conditional filtering using
notInis the appropriate approach for excluding multiple payout IDs from the query. The pattern matches the cutoff period filtering above and maintains consistency.apps/web/ui/partners/payout-invoice-sheet.tsx (4)
117-125: LGTM! State management for exclusion feature is well-implemented.The
excludedPayoutIdsstate and derivedincludedPayoutscalculation are properly structured with appropriate memoization and dependencies.
188-194: LGTM! Amount calculation correctly updated to use included payouts.The change from
eligiblePayoutstoincludedPayoutsensures the amount calculation excludes payouts that the user has chosen to exclude, which is the correct behavior.
321-341: LGTM! Good refactoring to extract partner column definition.Extracting the partner column into a memoized constant improves code readability while preserving the exact same functionality.
390-399: LGTM! Table styling appropriately updated for exclusion feature.The conditional styling provides clear visual feedback for excluded payouts with appropriate opacity changes and hover effects. The updated
tdClassNamefunction signature correctly accepts bothidandrowparameters for conditional styling.
|
@CodeRabbit final review |
|
Tip For best results, initiate chat on the files or code changes. @steven-tey I'll perform a final review of the changes that add the ability to exclude specific payouts from confirmation. [review] 🧠 Learnings used |
|
@CodeRabbit you didn't leave a review – can you do it again please? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain@steven-tey I'll perform a detailed review of the payout exclusion feature. Let me examine the implementation across all modified files. 🏁 Script executed: Length of output: 13844 🏁 Script executed: Length of output: 7223 🏁 Script executed: Length of output: 19598 @steven-tey I've completed a thorough review of the payout exclusion feature. Here's my assessment: ✅ Excellent ImplementationThis PR successfully adds the ability to exclude specific payouts from confirmation with a clean, consistent implementation across the entire stack. Key Strengths:
Technical Excellence:
Code Quality:
🎯 Minor Observations:The implementation is production-ready. The feature integrates perfectly with the existing payout limit validation system and maintains all security and business logic constraints. Overall Assessment: This is a well-architected feature that enhances user control over payout processing while maintaining system integrity. The code is clean, type-safe, and follows Dub's established patterns. 🐰 🧠 Learnings used |
Summary by CodeRabbit