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

Skip to content

Conversation

@devkiran
Copy link
Collaborator

@devkiran devkiran commented Sep 25, 2025

Summary by CodeRabbit

  • Bug Fixes
    • Improves Stripe payout processing by reliably associating payouts with the originating charge from successful payments, enhancing reconciliation accuracy.
    • Prevents duplicate associations for payouts that have already been processed, reducing the risk of errors in partner transfers.
    • Maintains existing behavior and error handling while increasing robustness in charge-to-payout linkage.

@vercel
Copy link
Contributor

vercel bot commented Sep 25, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Updated (UTC)
dub Ready Ready Preview Sep 26, 2025 0:20am

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Sep 25, 2025

Walkthrough

Threads Stripe chargeId through the payouts flow. The API route parses chargeId from invoice.stripeChargeMetadata and passes it to sendStripePayouts. sendStripePayouts updates its signature to accept chargeId and forwards it to createStripeTransfer, which conditionally sets source_transaction when no prior payouts exist.

Changes

Cohort / File(s) Summary
Charge-succeeded API route
apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts
Parse chargeId from invoice.stripeChargeMetadata via stripeChargeMetadataSchema and pass it into sendStripePayouts alongside invoiceId.
Payout orchestration
apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts
Update sendStripePayouts signature to accept { invoiceId, chargeId } and forward chargeId to createStripeTransfer in per-partner transfers.
Stripe transfer utility
apps/web/lib/partners/create-stripe-transfer.ts
Add optional chargeId param; include source_transaction: chargeId only when there are no previously processed payouts; otherwise omit source_transaction.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant CR as Charge-Succeeded Route
  participant DB as DB (Invoice)
  participant SP as sendStripePayouts
  participant PT as createStripeTransfer
  participant ST as Stripe Transfers API

  CR->>DB: Fetch invoice by invoiceId
  DB-->>CR: Invoice with stripeChargeMetadata
  Note over CR: Parse chargeId via stripeChargeMetadataSchema
  CR->>SP: sendStripePayouts({ invoiceId, chargeId })

  loop For each partner
    SP->>PT: createStripeTransfer({ ..., chargeId })
    alt No prior payouts
      PT->>ST: Create Transfer { source_transaction: chargeId }
    else Prior payouts exist
      PT->>ST: Create Transfer { no source_transaction }
    end
    ST-->>PT: Transfer result
    PT-->>SP: Transfer outcome
  end

  SP-->>CR: Payouts processed
  Note over CR,SP: Existing error handling unchanged
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested reviewers

  • steven-tey

Poem

I hop through ledgers, light and spry,
Threading chargeId needles nigh—
A tuft of code, a tidy trail,
From invoice burrow to payout vale.
Source_transactions set just right—
Carrots balanced, ledgers bright. 🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title clearly and concisely summarizes the primary change by stating that the source_transaction field is being added to the stripe.transfers.create call, which directly reflects the core update in the pull request. It is specific enough for a reviewer to understand the intent without unnecessary detail or jargon and avoids vague terms.
✨ 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-payouts

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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

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/payouts/charge-succeeded/send-stripe-payouts.ts (1)

7-95: Propagate optional chargeId through the payout flow

Once we allow the route to continue without a charge id, this signature needs to match. Treating chargeId as required will keep TypeScript satisfied yet still hand undefined to createStripeTransfer, producing an invalid source_transaction. Please make the parameter optional and only forward it when present.

-export async function sendStripePayouts({
-  invoiceId,
-  chargeId,
-}: {
-  invoiceId: string;
-  chargeId: string;
-}) {
+export async function sendStripePayouts({
+  invoiceId,
+  chargeId,
+}: {
+  invoiceId: string;
+  chargeId?: string;
+}) {
...
-      chargeId,
+      chargeId,
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 75afa6b and bf6051f.

📒 Files selected for processing (3)
  • apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (2 hunks)
  • apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts (2 hunks)
  • apps/web/lib/partners/create-stripe-transfer.ts (2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
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: 2025-07-11T16:28:55.693Z
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.

Applied to files:

  • apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts
  • apps/web/lib/partners/create-stripe-transfer.ts
🧬 Code graph analysis (1)
apps/web/app/(ee)/api/cron/payouts/charge-succeeded/route.ts (1)
apps/web/app/(ee)/api/cron/payouts/charge-succeeded/send-stripe-payouts.ts (1)
  • sendStripePayouts (7-118)
⏰ 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

@steven-tey steven-tey merged commit dda5f45 into main Sep 26, 2025
8 checks passed
@steven-tey steven-tey deleted the fix-payouts branch September 26, 2025 00:36
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.

3 participants