feat: add payout confirmation component to direct payout#188
Merged
aimensahnoun merged 2 commits intomainfrom Jan 13, 2026
Merged
Conversation
Contributor
WalkthroughA confirmation dialog flow has been integrated into the direct payout process. Payment submission now operates in two steps: preparing payment data and presenting a confirmation dialog, followed by executing the transaction upon user confirmation. The confirmation dialog's callback mechanism has been refactored from state-based storage to useRef. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant Component as DirectPayment Component
participant Dialog as PayoutConfirmationDialog
participant Wallet as Wallet/Provider
participant Blockchain as Blockchain Network
User->>Component: Submit Payment Form
Component->>Component: Prepare Payment Data
Component->>Component: Set Status: "confirming"
Component->>Dialog: Open Dialog (dialogRef.current?.open())
Dialog->>User: Display Confirmation Prompt
User->>Dialog: Confirm Payment
Dialog->>Component: Execute confirmCallback
Component->>Wallet: Check Network & Connection
Component->>Blockchain: Switch Network (if needed)
Component->>Component: Set Status: "processing"
Component->>Wallet: Request Approval (if needed)
Component->>Blockchain: Execute Payment Transaction
Blockchain-->>Component: Transaction Confirmed
Component->>Component: Set Status: "success"
Component->>User: Display Success Message
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
Member
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Jan 12, 2026
Greptile OverviewGreptile SummaryThis PR adds a confirmation dialog to the direct payout flow, separating payment preparation from execution to provide users with fee transparency before committing to transactions. The implementation introduces a What Changed
Critical Issues Found🚨 Payment Execution Failure (Critical): The most severe issue is a race condition in the confirm callback (lines 224-227). Due to React's asynchronous state updates, 🚨 Button Re-enablement Race Condition: Setting 🚨 Missing Wallet Provider Check: Lines 139-141 create an ethers provider without checking if Other Issues
Architecture ConcernsThe async state management pattern used here is fundamentally flawed. The data ( Confidence Score: 0/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant User
participant DirectPayment
participant Dialog as PayoutConfirmationDialog
participant API as Payment API
participant Wallet
participant Blockchain
User->>DirectPayment: Clicks "Send Payment"
DirectPayment->>DirectPayment: setPaymentStatus("processing")
DirectPayment->>API: pay(data)
API-->>DirectPayment: paymentData (with fees & transactions)
DirectPayment->>Dialog: show({amount, fees, walletAddress})
DirectPayment->>Dialog: onConfirm(callback)
DirectPayment->>DirectPayment: setPaymentStatus("idle") ⚠️
Note over DirectPayment: Button re-enabled while dialog open!
Dialog-->>User: Display confirmation with fees
alt User confirms
User->>Dialog: Clicks "Confirm & Send Payment"
Dialog->>Dialog: setOpen(false)
Dialog->>DirectPayment: Execute confirm callback
DirectPayment->>DirectPayment: setPendingPaymentData() ⚠️
Note over DirectPayment: State update is async!
DirectPayment->>DirectPayment: handleConfirmPayment() called
DirectPayment->>DirectPayment: Read pendingPaymentData ❌
Note over DirectPayment: Still null - payment won't execute!
alt If data was available (bug fixed)
DirectPayment->>Wallet: switchToPaymentNetwork()
Wallet-->>DirectPayment: Network switched
DirectPayment->>DirectPayment: setPaymentStatus("processing")
alt Approval needed
DirectPayment->>Wallet: sendTransaction(approval)
Wallet-->>User: Request approval signature
User->>Wallet: Approve
Wallet->>Blockchain: Submit approval tx
Blockchain-->>Wallet: Approval confirmed
end
DirectPayment->>Wallet: sendTransaction(payment)
Wallet-->>User: Request payment signature
User->>Wallet: Sign transaction
Wallet->>Blockchain: Submit payment tx
Blockchain-->>Wallet: Payment confirmed
Wallet-->>DirectPayment: Transaction success
DirectPayment->>User: Success toast
DirectPayment->>DirectPayment: setPaymentStatus("success")
DirectPayment->>DirectPayment: Reset form after 3s
end
else User cancels
User->>Dialog: Clicks "Cancel"
Dialog->>Dialog: setOpen(false)
Note over DirectPayment: No cleanup, button still enabled
end
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
Outdated
Show resolved
Hide resolved
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
Outdated
Show resolved
Hide resolved
Additional Comments (2)
The code assumes
Prompt To Fix With AIThis is a comment left during a code review.
Path: src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
Line: 156:160
Comment:
**Unsafe array access: Missing validation for approvalTransactionIndex**
The code assumes `approvalTransactionIndex` exists and is valid when `needsApproval` is true, but there's no null/undefined check. This can cause a crash if:
- The API returns `needsApproval: true` but omits `approvalTransactionIndex`
- The value is out of bounds for the `transactions` array
```suggestion
const approvalIndex = paymentData.metadata.approvalTransactionIndex;
if (approvalIndex === undefined || approvalIndex === null) {
throw new Error("Approval transaction index is missing");
}
if (approvalIndex >= paymentData.transactions.length || approvalIndex < 0) {
throw new Error("Invalid approval transaction index");
}
const approvalTransaction = await signer.sendTransaction(
paymentData.transactions[approvalIndex],
);
```
How can I resolve this? If you propose a fix, please make it concise.
Before accessing Prompt To Fix With AIThis is a comment left during a code review.
Path: src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
Line: 165:169
Comment:
**Missing validation: transactions array could be empty or undefined**
Before accessing `paymentData.transactions[...]`, the code should validate that the transactions array exists and has the expected elements. If the API returns an unexpected response, this could cause crashes.
```suggestion
if (!paymentData.transactions || paymentData.transactions.length === 0) {
throw new Error("No transactions returned from payment API");
}
const paymentTransactionIndex = isApprovalNeeded ? 1 : 0;
if (paymentTransactionIndex >= paymentData.transactions.length) {
throw new Error(`Expected ${isApprovalNeeded ? '2' : '1'} transaction(s), but got ${paymentData.transactions.length}`);
}
const paymentTransaction = await signer.sendTransaction(
paymentData.transactions[paymentTransactionIndex],
);
await paymentTransaction.wait();
```
How can I resolve this? If you propose a fix, please make it concise. |
aimensahnoun
force-pushed
the
01-12-feat_add_payout_confirmation_dialogue_component_that_showcases_fees
branch
from
b901c99 to
fd2c4f7
Compare
aimensahnoun
force-pushed
the
01-12-feat_add_payout_confirmation_component_to_direct_payout
branch
2 times, most recently
from
ff5383f to
a9ec460
Compare
rodrigopavezi
approved these changes
Jan 13, 2026
aimensahnoun
changed the base branch from
01-12-feat_add_payout_confirmation_dialogue_component_that_showcases_fees
to
graphite-base/188
aimensahnoun
force-pushed
the
graphite-base/188
branch
from
fd2c4f7 to
dcc77cf
Compare
aimensahnoun
force-pushed
the
01-12-feat_add_payout_confirmation_component_to_direct_payout
branch
from
a9ec460 to
08edb2b
Compare
aimensahnoun
force-pushed
the
01-12-feat_add_payout_confirmation_component_to_direct_payout
branch
from
08edb2b to
24ec17b
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx:
- Around line 229-242: The dialog closing path currently never resets
paymentStatus, leaving the UI stuck at "confirming"; update the dialog usage
around dialogRef to also handle cancellation/close by adding an onCancel or
onOpenChange handler (e.g., dialogRef.current?.onCancel or subscribe to
dialogRef.current.onOpenChange) that calls setPaymentStatus("idle") and any
other cleanup (re-enable fields) when the dialog closes without calling
onConfirm; keep the existing dialogRef.current?.onConfirm(() =>
handleConfirmPayment(...)) behavior intact so only non-confirm close events
trigger the reset.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsxsrc/components/payout-confirmation-dialog.tsx
🧰 Additional context used
📓 Path-based instructions (1)
**/*
⚙️ CodeRabbit configuration file
**/*: - Only comment on issues that would block merging — ignore minor or stylistic concerns.
- Restrict feedback to errors, security risks, or functionality-breaking problems.
- Do not post comments on code style, formatting, or non-critical improvements.
- Keep reviews short: flag only issues that make the PR unsafe to merge.
- Limit review comments to 3–5 items maximum, unless additional blockers exist.
- Group similar issues into a single comment instead of posting multiple notes.
- Skip repetition — if a pattern repeats, mention it once at a summary level only.
- Do not add general suggestions; focus strictly on merge-blocking concerns.
- If there are no critical problems, respond with minimal approval (e.g., 'Looks good'). Do not add additional review.
- Avoid line-by-line commentary unless it highlights a critical bug or security hole.
- Highlight only issues that could cause runtime errors, data loss, or severe maintainability issues.
- Ignore minor optimization opportunities — focus solely on correctness and safety.
- Provide a top-level summary of critical blockers rather than detailed per-line notes.
- Comment only when the issue must be resolved before merge — otherwise, remain silent.
- When in doubt, err on the side of fewer comments — brevity and blocking issues only.
- Avoid posting any refactoring issues
Files:
src/components/payout-confirmation-dialog.tsxsrc/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
🧠 Learnings (13)
📓 Common learnings
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 168
File: src/components/payment-widget/utils/payment.ts:86-87
Timestamp: 2025-10-28T12:17:42.971Z
Learning: The src/components/payment-widget/ directory contains an external component installed via ShadCN from the requestnetwork registry (https://ui.request.network/r/{name}.json) and should be treated as a vendored dependency. Modifications to files in this directory should not be suggested during code review.
Learnt from: rodrigopavezi
Repo: RequestNetwork/easy-invoice PR: 45
File: src/components/invoice-form.tsx:451-453
Timestamp: 2025-05-20T12:59:44.665Z
Learning: In the Easy Invoice project, setTimeout is required when submitting a form after modal state changes in the crypto-to-fiat payment flow. Directly calling handleFormSubmit without setTimeout after closing modals and updating state causes issues.
Learnt from: aimensahnoun
Repo: RequestNetwork/easy-invoice PR: 64
File: src/components/batch-payout.tsx:100-106
Timestamp: 2025-06-04T10:08:40.123Z
Learning: In src/components/batch-payout.tsx, the user prefers to keep the simple 2-second timeout for AppKit initialization over more complex polling mechanisms when the current approach is working adequately. They favor simplicity over potentially more robust but complex solutions.
📚 Learning: 2025-10-28T12:17:42.971Z
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 168
File: src/components/payment-widget/utils/payment.ts:86-87
Timestamp: 2025-10-28T12:17:42.971Z
Learning: The src/components/payment-widget/ directory contains an external component installed via ShadCN from the requestnetwork registry (https://ui.request.network/r/{name}.json) and should be treated as a vendored dependency. Modifications to files in this directory should not be suggested during code review.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-10-28T12:16:58.341Z
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 168
File: src/components/payment-widget/components/payment-success.tsx:57-60
Timestamp: 2025-10-28T12:16:58.341Z
Learning: The payment widget at src/components/payment-widget/** is an external component installed via ShadCN registry and should not receive detailed code modification suggestions. The project treats this directory as external/third-party code (configured in biome.json to be ignored).
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-10-28T12:17:14.899Z
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 168
File: src/components/payment-widget/README.md:29-31
Timestamp: 2025-10-28T12:17:14.899Z
Learning: The payment-widget component in src/components/payment-widget/ is an external component installed via ShadCN from the Request Network registry (https://ui.request.network). Its README and documentation should not be modified as it's maintained externally.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-10-28T12:17:03.639Z
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 168
File: src/components/payment-widget/context/payment-widget-context/payment-widget-provider.tsx:43-46
Timestamp: 2025-10-28T12:17:03.639Z
Learning: The payment widget components under src/components/payment-widget/ are installed via ShadCN from the Request Network registry and should not be modified locally to maintain compatibility with upstream.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-10-28T12:17:27.662Z
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 168
File: src/components/payment-widget/payment-widget.tsx:86-96
Timestamp: 2025-10-28T12:17:27.662Z
Learning: The src/components/payment-widget/ directory contains external components from the Request Network component registry and should not be modified locally, similar to how ShadCN components are treated.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-05-19T13:00:48.790Z
Learnt from: rodrigopavezi
Repo: RequestNetwork/easy-invoice PR: 45
File: src/components/invoice-form.tsx:316-319
Timestamp: 2025-05-19T13:00:48.790Z
Learning: The handleFormSubmit function in src/components/invoice-form.tsx correctly uses data.clientEmail from the form submission data to find matching payers, which is the proper implementation.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-05-20T12:59:44.665Z
Learnt from: rodrigopavezi
Repo: RequestNetwork/easy-invoice PR: 45
File: src/components/invoice-form.tsx:451-453
Timestamp: 2025-05-20T12:59:44.665Z
Learning: In the Easy Invoice project, setTimeout is required when submitting a form after modal state changes in the crypto-to-fiat payment flow. Directly calling handleFormSubmit without setTimeout after closing modals and updating state causes issues.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-06-04T10:08:40.123Z
Learnt from: aimensahnoun
Repo: RequestNetwork/easy-invoice PR: 64
File: src/components/batch-payout.tsx:100-106
Timestamp: 2025-06-04T10:08:40.123Z
Learning: In src/components/batch-payout.tsx, the user prefers to keep the simple 2-second timeout for AppKit initialization over more complex polling mechanisms when the current approach is working adequately. They favor simplicity over potentially more robust but complex solutions.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-10-13T19:12:34.359Z
Learnt from: MantisClone
Repo: RequestNetwork/easy-invoice PR: 0
File: :0-0
Timestamp: 2025-10-13T19:12:34.359Z
Learning: In `src/server/routers/ecommerce.ts`, the `create` procedure for client IDs should use `?? undefined` for `feePercentage` and `feeAddress` when calling the external API, because the backend create endpoint uses `.optional()` and rejects `null`. However, the `edit` procedure should use `?? null` for these fields because the backend update endpoint uses `.nullable().optional()`, which allows `null` values to support explicitly unsetting fees.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-06-23T09:14:42.979Z
Learnt from: bassgeta
Repo: RequestNetwork/easy-invoice PR: 83
File: src/components/create-recurring-payment/blocks/create-recurring-payment-form.tsx:127-138
Timestamp: 2025-06-23T09:14:42.979Z
Learning: In the RequestNetwork/easy-invoice codebase, when suggesting improvements like error handling for transaction approvals, the user bassgeta prefers consistency over isolated improvements. They prefer not to implement error handling in one place unless it's done consistently across all similar transaction flows in the codebase.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-06-04T12:02:39.411Z
Learnt from: aimensahnoun
Repo: RequestNetwork/easy-invoice PR: 67
File: src/server/routers/payment.ts:47-49
Timestamp: 2025-06-04T12:02:39.411Z
Learning: In `src/server/routers/payment.ts`, the batchPay input validation already handles empty arrays correctly. The `batchPaymentFormSchema.shape.payouts.optional()` inherits the `.min(1, "At least one payment is required")` validation from the original schema, so empty payouts arrays are automatically rejected even when the field is made optional.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
📚 Learning: 2025-02-27T14:02:35.047Z
Learnt from: aimensahnoun
Repo: RequestNetwork/easy-invoice PR: 23
File: src/components/direct-payment.tsx:343-360
Timestamp: 2025-02-27T14:02:35.047Z
Learning: For the DirectPayment component, amount validation is already handled through Zod schema validation in paymentFormSchema, which ensures the amount is greater than zero.
Applied to files:
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx
🧬 Code graph analysis (1)
src/app/(dashboard)/payouts/direct/_components/direct-payout.tsx (2)
src/components/payout-confirmation-dialog.tsx (2)
PayoutConfirmationDialogRef(28-32)PayoutConfirmationDialog(34-498)src/components/ui/card.tsx (2)
CardFooter(79-79)Card(79-79)
⏰ 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
Member
Author
Merge activity
|
aimensahnoun
deleted the
01-12-feat_add_payout_confirmation_component_to_direct_payout
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
Added a confirmation dialog for direct payouts to improve the payment flow and user experience.
What changed?
PayoutConfirmationDialogcomponent to the direct payout flowHow to test?
Why make this change?
This change improves the user experience by providing a clear confirmation step before executing blockchain transactions. It gives users visibility into fees before committing to a payment and creates a more deliberate payment flow that reduces the chance of errors. The separation of payment preparation from execution also makes the code more maintainable and easier to debug.
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.