feat: add active subscribers table and payments table #98
Conversation
WalkthroughThis change introduces a tabbed interface for subscription plans, adding new tables for subscribers and payments with filtering and summary statistics. It implements soft deletion and active filtering for subscription plans, updates the recurring payments schema, and enhances backend procedures for subscriber/payment retrieval. Several new React components and types are added. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI as Subscription Plans Page
participant API as Server API
participant DB
User->>UI: Navigate to Subscription Plans
UI->>API: Fetch subscription plans, subscribers, payments
API->>DB: Query active plans, subscribers, payments
DB-->>API: Return data
API-->>UI: Return data
UI->>User: Display tabbed interface (Plans, Subscribers, Payments)
User->>UI: Delete a subscription plan
UI->>API: Cancel all active recurring payments for plan
API->>DB: Update recurring payments status
DB-->>API: Confirm cancellations
API->>DB: Soft delete (set active=false) subscription plan
DB-->>API: Confirm deletion
API-->>UI: Return success
UI->>User: Show success toast
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes detected related to the objectives in the linked issues. Possibly related PRs
Suggested reviewers
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 (7)
✅ Files skipped from review due to trivial changes (3)
🚧 Files skipped from review as they are similar to previous changes (2)
🧰 Additional context used🧠 Learnings (6)📓 Common learnings📚 Learning: the handleformsubmit function in src/components/invoice-form.tsx correctly uses data.clientemail fro...Applied to files:
📚 Learning: the payrequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicp...Applied to files:
📚 Learning: the `payrequest` function in the invoice router retrieves payment transactions calldata from the req...Applied to files:
📚 Learning: the `v2/payouts/recurring/{externalpaymentid}` patch endpoint in the requestnetwork/easy-invoice pro...Applied to files:
📚 Learning: in the requestnetwork/easy-invoice codebase, the user aimensahnoun prefers to keep recurring payment...Applied to files:
🔇 Additional comments (4)
✨ Finishing Touches
🧪 Generate unit tests
🪧 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/components/subscription-plans/blocks/subscribers-table.tsx (1)
89-92: Consider improving currency display formatting.The current implementation concatenates amount and currency with a "$" prefix, which may result in confusing display like "$100 $USDC". Consider using a more consistent currency formatting approach.
- <div className="text-sm"> - {Number(subscription.totalAmount).toLocaleString()} $ - {subscription.paymentCurrency} - </div> + <div className="text-sm"> + {Number(subscription.totalAmount).toLocaleString()} {formatCurrencyLabel(subscription.paymentCurrency)} + </div>src/components/subscription-plans/blocks/subscription-plan-link.tsx (1)
84-98: Consider improving error visibility for failed cancellations.While the current approach continues processing even if individual cancellations fail, the silent error handling (only console.error) might leave users unaware of partial failures.
Consider tracking failed cancellations and informing the user:
+ const failedCancellations: string[] = []; for (const payment of recurringPayments) { try { await cancelRecurringPayment(payment); } catch (error) { console.error(`Failed to cancel payment ${payment.id}:`, error); + failedCancellations.push(payment.id); } } + + if (failedCancellations.length > 0) { + toast.warning(`${failedCancellations.length} subscription(s) could not be cancelled. The plan will still be deleted.`); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
src/app/subscription-plans/page.tsx(2 hunks)src/components/dashboard/subscriptions.tsx(2 hunks)src/components/subscription-plans/blocks/subscribers-table.tsx(1 hunks)src/components/subscription-plans/blocks/subscription-plan-link.tsx(5 hunks)src/components/subscription-plans/blocks/subscription-plans-list.tsx(1 hunks)src/components/subscription-plans/subscription-plan-tabs.tsx(1 hunks)src/components/subscription-plans/subscription-plans.tsx(0 hunks)src/components/view-recurring-payments/view-recurring-payments.tsx(1 hunks)src/lib/hooks/use-cancel-recurring-payment.ts(0 hunks)src/lib/types/index.ts(2 hunks)src/server/routers/subscription-plan.ts(3 hunks)
🧠 Learnings (4)
src/components/view-recurring-payments/view-recurring-payments.tsx (2)
Learnt from: rodrigopavezi
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.
Learnt from: aimensahnoun
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.
src/lib/types/index.ts (4)
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: aimensahnoun
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.
Learnt from: aimensahnoun
PR: #42
File: src/components/payment-section.tsx:534-544
Timestamp: 2025-03-25T09:31:47.519Z
Learning: In the PaymentSection component of EasyInvoice, selectedRoute is automatically set to the first route when payment routes are loaded, and users can only switch between routes, not deselect them entirely.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:0-0
Timestamp: 2025-02-12T13:04:46.135Z
Learning: The payRequest function in the invoice router retrieves payment transactions calldata from the Request API and does not process the payment itself. The actual payment status update happens through the webhook handler.
src/server/routers/subscription-plan.ts (3)
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
Learnt from: aimensahnoun
PR: #8
File: src/app/invoice-me/page.tsx:21-21
Timestamp: 2025-02-14T12:48:42.125Z
Learning: In the easy-invoice codebase, error handling for TRPC queries is not required at the component level as confirmed by the maintainer.
src/components/subscription-plans/blocks/subscription-plan-link.tsx (1)
Learnt from: rodrigopavezi
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.
🧬 Code Graph Analysis (5)
src/lib/types/index.ts (1)
src/server/db/schema.ts (1)
RecurringPayment(393-393)
src/app/subscription-plans/page.tsx (3)
src/components/subscription-plans/blocks/subscription-plans-list.tsx (1)
SubscriptionPlansList(14-47)src/components/subscription-plans/blocks/subscribers-table.tsx (1)
SubscribersTable(102-209)src/components/subscription-plans/subscription-plan-tabs.tsx (1)
SubscriptionPlanTabs(10-30)
src/server/routers/subscription-plan.ts (2)
src/server/trpc.ts (1)
protectedProcedure(39-39)src/server/db/schema.ts (2)
subscriptionPlanTable(282-298)recurringPaymentTable(218-256)
src/components/subscription-plans/blocks/subscription-plan-link.tsx (5)
src/server/db/schema.ts (1)
SubscriptionPlan(388-388)src/lib/hooks/use-cancel-recurring-payment.ts (1)
useCancelRecurringPayment(14-92)src/lib/constants/currencies.ts (1)
formatCurrencyLabel(94-139)src/components/ui/alert-dialog.tsx (9)
AlertDialog(130-130)AlertDialogTrigger(133-133)AlertDialogContent(134-134)AlertDialogHeader(135-135)AlertDialogTitle(137-137)AlertDialogDescription(138-138)AlertDialogFooter(136-136)AlertDialogCancel(140-140)AlertDialogAction(139-139)src/components/ui/button.tsx (1)
Button(56-56)
src/components/subscription-plans/blocks/subscribers-table.tsx (12)
src/lib/types/index.ts (1)
SubscriptionWithDetails(14-20)src/server/db/schema.ts (1)
SubscriptionPlan(388-388)src/components/ui/table.tsx (5)
TableRow(114-114)TableCell(115-115)Table(109-109)TableHeader(110-110)TableBody(111-111)src/components/dashboard/blocks/table-head-cell.tsx (1)
TableHeadCell(9-13)src/components/view-recurring-payments/blocks/frequency-badge.tsx (1)
FrequencyBadge(17-23)src/lib/constants/currencies.ts (1)
formatCurrencyLabel(94-139)src/components/short-address.tsx (1)
ShortAddress(12-37)src/components/view-recurring-payments/blocks/completed-payments.tsx (1)
CompletedPayments(14-68)src/components/dashboard/blocks/stat-card.tsx (1)
StatCard(9-21)src/components/ui/select.tsx (5)
Select(150-150)SelectTrigger(153-153)SelectValue(152-152)SelectContent(154-154)SelectItem(156-156)src/components/ui/card.tsx (2)
Card(79-79)CardContent(79-79)src/components/dashboard/blocks/empty-state.tsx (1)
EmptyState(10-24)
💤 Files with no reviewable changes (2)
- src/lib/hooks/use-cancel-recurring-payment.ts
- src/components/subscription-plans/subscription-plans.tsx
🧰 Additional context used
🧠 Learnings (4)
src/components/view-recurring-payments/view-recurring-payments.tsx (2)
Learnt from: rodrigopavezi
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.
Learnt from: aimensahnoun
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.
src/lib/types/index.ts (4)
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: aimensahnoun
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.
Learnt from: aimensahnoun
PR: #42
File: src/components/payment-section.tsx:534-544
Timestamp: 2025-03-25T09:31:47.519Z
Learning: In the PaymentSection component of EasyInvoice, selectedRoute is automatically set to the first route when payment routes are loaded, and users can only switch between routes, not deselect them entirely.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:0-0
Timestamp: 2025-02-12T13:04:46.135Z
Learning: The payRequest function in the invoice router retrieves payment transactions calldata from the Request API and does not process the payment itself. The actual payment status update happens through the webhook handler.
src/server/routers/subscription-plan.ts (3)
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
Learnt from: aimensahnoun
PR: #8
File: src/app/invoice-me/page.tsx:21-21
Timestamp: 2025-02-14T12:48:42.125Z
Learning: In the easy-invoice codebase, error handling for TRPC queries is not required at the component level as confirmed by the maintainer.
src/components/subscription-plans/blocks/subscription-plan-link.tsx (1)
Learnt from: rodrigopavezi
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.
🧬 Code Graph Analysis (5)
src/lib/types/index.ts (1)
src/server/db/schema.ts (1)
RecurringPayment(393-393)
src/app/subscription-plans/page.tsx (3)
src/components/subscription-plans/blocks/subscription-plans-list.tsx (1)
SubscriptionPlansList(14-47)src/components/subscription-plans/blocks/subscribers-table.tsx (1)
SubscribersTable(102-209)src/components/subscription-plans/subscription-plan-tabs.tsx (1)
SubscriptionPlanTabs(10-30)
src/server/routers/subscription-plan.ts (2)
src/server/trpc.ts (1)
protectedProcedure(39-39)src/server/db/schema.ts (2)
subscriptionPlanTable(282-298)recurringPaymentTable(218-256)
src/components/subscription-plans/blocks/subscription-plan-link.tsx (5)
src/server/db/schema.ts (1)
SubscriptionPlan(388-388)src/lib/hooks/use-cancel-recurring-payment.ts (1)
useCancelRecurringPayment(14-92)src/lib/constants/currencies.ts (1)
formatCurrencyLabel(94-139)src/components/ui/alert-dialog.tsx (9)
AlertDialog(130-130)AlertDialogTrigger(133-133)AlertDialogContent(134-134)AlertDialogHeader(135-135)AlertDialogTitle(137-137)AlertDialogDescription(138-138)AlertDialogFooter(136-136)AlertDialogCancel(140-140)AlertDialogAction(139-139)src/components/ui/button.tsx (1)
Button(56-56)
src/components/subscription-plans/blocks/subscribers-table.tsx (12)
src/lib/types/index.ts (1)
SubscriptionWithDetails(14-20)src/server/db/schema.ts (1)
SubscriptionPlan(388-388)src/components/ui/table.tsx (5)
TableRow(114-114)TableCell(115-115)Table(109-109)TableHeader(110-110)TableBody(111-111)src/components/dashboard/blocks/table-head-cell.tsx (1)
TableHeadCell(9-13)src/components/view-recurring-payments/blocks/frequency-badge.tsx (1)
FrequencyBadge(17-23)src/lib/constants/currencies.ts (1)
formatCurrencyLabel(94-139)src/components/short-address.tsx (1)
ShortAddress(12-37)src/components/view-recurring-payments/blocks/completed-payments.tsx (1)
CompletedPayments(14-68)src/components/dashboard/blocks/stat-card.tsx (1)
StatCard(9-21)src/components/ui/select.tsx (5)
Select(150-150)SelectTrigger(153-153)SelectValue(152-152)SelectContent(154-154)SelectItem(156-156)src/components/ui/card.tsx (2)
Card(79-79)CardContent(79-79)src/components/dashboard/blocks/empty-state.tsx (1)
EmptyState(10-24)
⏰ 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 (21)
src/lib/types/index.ts (2)
1-2: Good addition of centralized type definition.The import and export of
SubscriptionWithDetailstype centralizes what was previously duplicated across components, improving maintainability.
14-20: Well-structured type definition.The
SubscriptionWithDetailstype properly extendsRecurringPaymentwith subscription metadata. The nullable subscription property correctly handles cases where subscription details might not be available.src/components/dashboard/subscriptions.tsx (2)
16-16: Good use of centralized type definition.Using the
SubscriptionWithDetailstype from the centralized location instead of a local definition improves maintainability.
66-68: Explicit confirmation dialog improves clarity.Moving the confirmation dialog from the hook configuration to an explicit
confirm()call in the event handler makes the user interaction flow more transparent and easier to customize.src/components/view-recurring-payments/view-recurring-payments.tsx (1)
57-59: Consistent confirmation dialog pattern.The explicit confirmation dialog matches the pattern used in other components, providing consistency across the application for user confirmation flows.
src/app/subscription-plans/page.tsx (5)
3-5: Well-organized imports for new tabbed interface.The new imports properly separate concerns with dedicated components for subscribers table, plans list, and tab management, along with appropriate UI components.
Also applies to: 8-9
20-20: Good addition of subscribers data fetching.Adding the
getAllSubscribersquery provides the necessary data for the new subscribers tab functionality.
22-30: Clean separation of tab content.Creating separate variables for
plansTabandsubscribersTabcontent improves readability and makes the component structure clear.
35-46: Well-implemented navigation header.The header section with back navigation and page title provides good UX. The responsive container classes appropriately handle different screen sizes.
48-51: Effective use of tabbed interface.The
SubscriptionPlanTabscomponent provides a clean way to organize the plans and subscribers views in a single interface.src/components/subscription-plans/subscription-plan-tabs.tsx (1)
1-30: Well-designed tabbed interface component.The component follows React best practices with:
- Clear prop interface with appropriate types
- Sensible default tab selection ("plans")
- Clean delegation of content rendering to props
- Consistent styling with grid layout and spacing
The implementation is simple, focused, and reusable.
src/components/subscription-plans/blocks/subscription-plans-list.tsx (1)
1-47: LGTM! Clean and well-structured component implementation.The component follows React best practices with proper state management, TRPC integration with initial data hydration, and clean separation of concerns. The modal handling and conditional rendering are implemented correctly.
src/server/routers/subscription-plan.ts (3)
3-3: LGTM! Appropriate import additions for new query functionality.The
inArrayandnotimports are correctly added to support the new filtering logic in the subscriber queries.
81-109: Well-implemented getAllSubscribers procedure with proper security and filtering.The implementation correctly:
- Uses
protectedProcedurefor authentication- Filters by user ownership through subscription plans
- Excludes cancelled payments consistently
- Includes necessary subscription metadata
- Orders results appropriately
The two-query approach (plans first, then payments) ensures data consistency and proper authorization.
130-133: Excellent consistency improvement by excluding cancelled payments.The modification aligns the
getSubscribersForPlanprocedure with the newgetAllSubscribersfiltering logic, ensuring cancelled subscriptions are consistently excluded across both endpoints.src/components/subscription-plans/blocks/subscribers-table.tsx (3)
125-130: Revenue calculation logic is correct and well-implemented.The revenue calculation properly filters for active statuses and safely handles potential null/undefined values with fallbacks.
183-183: Verify column span matches actual table structure.Ensure the
colSpan={7}matches the number of table columns defined inSubscriberTableColumns(currently 7 columns: Start Date, Plan Name, Trial Info, Frequency, Currency, Subscriber, Payment History).
102-209: Excellent component architecture with comprehensive functionality.The component demonstrates good practices:
- Proper state management and data fetching
- Clear separation of concerns with sub-components
- Comprehensive filtering and statistics
- Well-structured UI with proper empty states
- Consistent use of design system components
src/components/subscription-plans/blocks/subscription-plan-link.tsx (3)
30-30: Good solution for Next.js hydration issues.The mounted state pattern correctly handles the hydration mismatch between server and client for dynamic URL construction.
Also applies to: 35-38
170-215: Excellent modal implementation with proper state management.The AlertDialog integration includes:
- Controlled open state
- Proper loading states on buttons
- Clear warning messages for users with active subscribers
- Disabled states during processing to prevent race conditions
51-59: Well-integrated cancellation hook with proper cache invalidation.The hook integration correctly invalidates both plan-specific and global subscriber caches after successful cancellation operations.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
src/components/subscription-plans/subscription-plan-tabs.tsx (1)
1-37: Clean and well-structured tabs component.The implementation is solid with good TypeScript typing and proper component structure. The component serves its purpose well as a presentational container for the tabbed interface.
Consider adding
aria-labelto theTabscomponent for better accessibility:- <Tabs defaultValue="plans" className="w-full"> + <Tabs defaultValue="plans" className="w-full" aria-label="Subscription management tabs">src/server/routers/subscription-plan.ts (1)
82-110: Implementation looks correct.The procedure properly fetches user's subscription plans and filters subscribers excluding cancelled ones. The use of relationships to include subscription details is appropriate.
For better performance with large datasets, consider using a single query with joins instead of two separate queries:
const subscribers = await db .select({ // ... recurring payment fields subscription: { id: subscriptionPlanTable.id, label: subscriptionPlanTable.label, trialDays: subscriptionPlanTable.trialDays, } }) .from(recurringPaymentTable) .innerJoin(subscriptionPlanTable, eq(recurringPaymentTable.subscriptionId, subscriptionPlanTable.id)) .where(and( eq(subscriptionPlanTable.userId, user.id), not(eq(recurringPaymentTable.status, "cancelled")) )) .orderBy(desc(recurringPaymentTable.createdAt));src/components/subscription-plans/blocks/payments-table.tsx (2)
44-88: Helper components are well-implemented.Both
PaymentTableColumnsandPaymentRoware clean and functional. Good use of utility functions for formatting and proper handling of external links.Consider improving the currency display format in the amount cell:
- {Number(payment.amount).toLocaleString()} ${payment.currency} + ${payment.currency} {Number(payment.amount).toLocaleString()}This would display as "USDC 1,000" instead of "1,000 $USDC" which might be more natural for users.
129-140: Statistics cards provide good user insights.The implementation correctly shows metrics based on filtered data with appropriate formatting.
Consider handling multi-currency scenarios in the revenue calculation. Currently, it sums all amounts regardless of currency, which might be misleading if payments are in different currencies:
const totalRevenue = filteredPayments.reduce((acc, payment) => { const currency = payment.currency; if (!acc[currency]) acc[currency] = 0; acc[currency] += Number(payment.amount); return acc; }, {} as Record<string, number>);Then display multiple currency totals or convert to a base currency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/app/subscription-plans/page.tsx(2 hunks)src/components/subscription-plans/blocks/payments-table.tsx(1 hunks)src/components/subscription-plans/blocks/subscribers-table.tsx(1 hunks)src/components/subscription-plans/subscription-plan-tabs.tsx(1 hunks)src/lib/types/index.ts(2 hunks)src/server/routers/subscription-plan.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/app/subscription-plans/page.tsx
- src/lib/types/index.ts
- src/components/subscription-plans/blocks/subscribers-table.tsx
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
src/components/subscription-plans/blocks/payments-table.tsx (2)
Learnt from: rodrigopavezi
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.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
src/server/routers/subscription-plan.ts (3)
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
Learnt from: aimensahnoun
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.
🧬 Code Graph Analysis (2)
src/components/subscription-plans/subscription-plan-tabs.tsx (1)
src/components/ui/tabs.tsx (4)
Tabs(55-55)TabsList(55-55)TabsTrigger(55-55)TabsContent(55-55)
src/components/subscription-plans/blocks/payments-table.tsx (8)
src/lib/types/index.ts (1)
SubscriptionPayment(22-32)src/server/db/schema.ts (1)
SubscriptionPlan(389-389)src/components/dashboard/blocks/table-head-cell.tsx (1)
TableHeadCell(9-13)src/lib/constants/currencies.ts (1)
formatCurrencyLabel(94-139)src/components/short-address.tsx (1)
ShortAddress(12-37)src/components/dashboard/blocks/stat-card.tsx (1)
StatCard(9-21)src/components/dashboard/blocks/empty-state.tsx (1)
EmptyState(10-24)src/components/dashboard/blocks/pagination.tsx (1)
Pagination(10-45)
⏰ 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 (6)
src/server/routers/subscription-plan.ts (3)
2-4: Imports look good.The new imports are appropriate for the implemented functionality -
SubscriptionPaymentfor typing, andinArray/notfor the new filtering logic.
179-182: Good consistency improvement.Adding the cancelled status filter maintains consistency with the new procedures and ensures cancelled subscriptions are properly excluded.
111-158: Verify payment date mapping and webhook integrationThe
paymentsJSON field onrecurringPaymentTableis defined as an array of{ date: string; txHash: string; requestScanUrl?: string }and the reduce logic correctly guards against
null/empty arrays. The composite ID format${subscriber.id}-${payment.txHash}is safe sincetxHashis unique per transaction.Please review the webhook event handling to confirm that
payment.datetruly reflects the on-chain transaction timestamp (and isn’t, for example, the date when the webhook was received).
- Check the
payment.createdcase insrc/app/api/webhook/route.tsand ensure it assigns the correct timestamp topayment.date.src/components/subscription-plans/blocks/payments-table.tsx (3)
1-37: Imports and constants are well-organized.The comprehensive import set covers all the required functionality and the pagination constant is appropriately set.
90-103: Component setup follows best practices.Good use of initial data hydration with TRPC and appropriate state management for pagination and filtering.
142-204: Table rendering and pagination are well-implemented.Excellent user experience with contextual empty states, proper filter controls, and conditional pagination. The component handles all edge cases appropriately.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/server/routers/recurring-payment.ts (1)
193-247: Secure implementation with proper validation flow.The mutation correctly implements subscription-scoped authorization and follows the established security patterns. The validation logic ensures proper access control before making external API calls.
Consider extracting the common API call logic (lines 232-244) into a shared helper function to reduce duplication with the existing
updateRecurringPaymentmutation:private async callUpdateRecurringPaymentAPI(externalPaymentId: string, action: string) { const response = await apiClient.patch( `v2/payouts/recurring/${externalPaymentId}`, { action } ); if (response.status !== 200) { throw new TRPCError({ code: "INTERNAL_SERVER_ERROR", message: "Failed to update recurring payment", }); } return response.data as UpdateRecurringPaymentResponse; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
drizzle/0008_mysterious_celestials.sql(1 hunks)drizzle/meta/0008_snapshot.json(1 hunks)drizzle/meta/_journal.json(1 hunks)src/components/subscription-plans/blocks/subscription-plan-link.tsx(5 hunks)src/lib/hooks/use-cancel-recurring-payment.ts(4 hunks)src/server/db/schema.ts(2 hunks)src/server/routers/recurring-payment.ts(4 hunks)src/server/routers/subscription-plan.ts(7 hunks)
✅ Files skipped from review due to trivial changes (2)
- drizzle/meta/_journal.json
- drizzle/0008_mysterious_celestials.sql
🚧 Files skipped from review as they are similar to previous changes (5)
- src/server/db/schema.ts
- src/lib/hooks/use-cancel-recurring-payment.ts
- src/components/subscription-plans/blocks/subscription-plan-link.tsx
- src/server/routers/subscription-plan.ts
- drizzle/meta/0008_snapshot.json
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
src/server/routers/recurring-payment.ts (6)
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:0-0
Timestamp: 2025-02-12T13:04:46.135Z
Learning: The payRequest function in the invoice router retrieves payment transactions calldata from the Request API and does not process the payment itself. The actual payment status update happens through the webhook handler.
Learnt from: bassgeta
PR: #82
File: src/server/routers/recurring-payment.ts:143-148
Timestamp: 2025-07-11T12:56:11.332Z
Learning: The v2/payouts/recurring/{externalPaymentId} PATCH endpoint in the RequestNetwork/easy-invoice project specifically returns a 200 status code on success or an error status code - it does not return other 2xx success codes like 201 or 204. The status check response.status !== 200 is correct for this specific endpoint.
Learnt from: aimensahnoun
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.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
Learnt from: MantisClone
PR: #59
File: src/app/api/webhook/route.ts:77-95
Timestamp: 2025-05-22T18:19:12.366Z
Learning: For webhook handlers in the Easy Invoice project, unknown or unexpected subStatus values in payment processing should be treated as errors (using console.error) rather than warnings, and should return a 422 Unprocessable Entity status code.
🧬 Code Graph Analysis (1)
src/server/routers/recurring-payment.ts (4)
src/server/trpc.ts (1)
protectedProcedure(39-39)src/server/db/schema.ts (3)
RecurringPaymentStatus(70-76)subscriptionPlanTable(283-300)recurringPaymentTable(218-257)src/server/db/index.ts (1)
db(10-12)src/lib/axios.ts (1)
apiClient(3-8)
⏰ 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)
src/server/routers/recurring-payment.ts (3)
7-11: Import changes look good.The addition of
subscriptionPlanTableto the imports is necessary for the new subscription-scoped mutations and follows the established import pattern.
57-57: Addition of payer field is consistent with schema updates.The new
payerfield correctly captures the payer information and aligns with the database schema changes mentioned in the PR objectives.
105-150: Well-implemented subscription-scoped authorization.This mutation properly validates subscription plan ownership before allowing status updates. The two-step validation (subscription ownership + recurring payment existence) provides good security boundaries and prevents unauthorized access to recurring payments across different subscriptions.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
src/components/subscription-plans/blocks/payments-table.tsx (3)
55-88: Consider improving currency display formatting.The payment row component is well-structured, but the currency display could be improved for better internationalization.
Consider using the
formatCurrencyLabelutility more consistently:<TableCell> <span className="font-semibold"> - {Number(payment.amount).toLocaleString()} ${payment.currency} + {Number(payment.amount).toLocaleString()} {formatCurrencyLabel(payment.currency)} </span> </TableCell>This ensures consistent currency symbol formatting across the application.
105-111: Filtering logic correctly implemented using plan ID.Great improvement! The filtering now uses
payment.planId === activePlanwhich addresses the reliability concerns from previous reviews about filtering by plan name.Consider multi-currency handling in revenue calculation.
The revenue calculation sums amounts across potentially different currencies, which could be misleading.
Consider grouping revenue by currency or adding a note about mixed currencies:
const totalRevenue = filteredPayments.reduce((sum, payment) => { return sum + Number(payment.amount); }, 0); + + const currencies = [...new Set(filteredPayments.map(p => p.currency))]; + const isMultiCurrency = currencies.length > 1;Then display currency information in the StatCard or add a disclaimer for mixed currencies.
167-180: Clean empty state handling with contextual messaging.The empty state implementation provides helpful contextual messages based on the filter state, which enhances user experience.
Minor simplification opportunity for empty state check.
The condition could be simplified since
filteredPaymentsshould always be defined:- {!filteredPayments || filteredPayments.length === 0 ? ( + {filteredPayments.length === 0 ? (
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/components/subscription-plans/blocks/payments-table.tsx(1 hunks)src/lib/types/index.ts(2 hunks)src/server/routers/subscription-plan.ts(7 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/lib/types/index.ts
- src/server/routers/subscription-plan.ts
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
src/components/subscription-plans/blocks/payments-table.tsx (3)
Learnt from: rodrigopavezi
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.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: aimensahnoun
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.
⏰ 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 (2)
src/components/subscription-plans/blocks/payments-table.tsx (2)
1-42: Well-structured component setup with proper typing.The imports are well-organized and the interface definitions are clear. The use of TypeScript interfaces provides good type safety for the component props.
90-200: Well-architected component with good performance and UX considerations.The PaymentsTable component demonstrates solid React architecture with proper state management, performance optimizations through pagination, and good user experience with filtering and contextual empty states.
bassgeta
changed the title
|
Creating a Subscription Plan should not require connecting a wallet because it doesn't require a signature. Instead, the Create Subscription Plan component should include a "Payee" address field, with proper address validation. This problem is out of scope of the current Pull Request. @coderabbitai, make an issue to fix this problem. Additionally, the Reown AppKit Connect Wallet widget lacks a scroll, so the "All Wallets" option is partially offscreen. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain@MantisClone, I'll create GitHub issues for both problems you've identified. Let me create these issues for you now. 🏁 Script executed: Length of output: 2360 Perfect! I've successfully created both GitHub issues for you: Issue #100: Subscription Plan creation should not require wallet connection and should include payee address field🔗 #100 This issue covers:
Issue #101: Reown AppKit Connect Wallet widget lacks scroll - "All Wallets" option partially offscreen🔗 #101 This issue covers:
Both issues have been assigned to you (@MantisClone) and include the context from this PR review, along with the screenshots you provided. The issues are now ready for prioritization and implementation in future development cycles. 🧠 Learnings used |
This comment was marked as duplicate.
This comment was marked as duplicate.
🔄 Missing Real-time Updates for Subscription ComponentsCurrent State Analysis✅ Invoice Components (Dashboard Get Paid/Pay tabs):
❌ Subscription Components (This PR):
Components Requiring 3-Second PollingThe following components need the same polling configuration as invoices: 1. Dashboard - Subscriptions Table (subscriptions.tsx)// Current (❌ Static data)
const { data: subscriptions } = api.subscriptionPlan.getUserActiveSubscriptions.useQuery(undefined, {
initialData: initialSubscriptions,
});
// Required (✅ Real-time updates)
const { data: subscriptions } = api.subscriptionPlan.getUserActiveSubscriptions.useQuery(undefined, {
initialData: initialSubscriptions,
refetchOnMount: true,
refetchOnReconnect: true,
refetchInterval: 3000, // Same as invoices
});2. Subscription Plans - Plans List (subscription-plans-list.tsx)3. Subscription Plans - Subscribers Table (subscribers-table.tsx)4. Subscription Plans - Payments Table (payments-table.tsx)All need the same three options: Recommended Implementation
const RETRIEVE_SUBSCRIPTION_DATA_POLLING_INTERVAL = 3000; // Match invoices
Acceptance Criteria
This should be implemented before merging to maintain consistency with invoice polling behavior and provide real-time updates for financial data. |
src/components/subscription-plans/blocks/subscription-plan-link.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
src/components/subscription-plans/blocks/subscription-plan-link.tsx (1)
91-118: Race condition issue acknowledged.The sequential payment cancellation logic still has the race condition issue identified in previous review comments. This has been properly documented and tracked in issue #103 for future implementation.
src/components/subscription-plans/blocks/payments-table.tsx (2)
133-135: Filtering logic correctly fixed to use planId.The filtering now uses stable plan IDs instead of plan names, making it robust against plan name changes as addressed in previous review comments.
137-139: Currency aggregation issue is application-wide.As noted in previous comments and confirmed by the maintainer, the mixed-currency summation issue exists across the entire application (dashboard stats, etc.). This should be addressed consistently application-wide rather than in isolation.
Also applies to: 160-162
🧹 Nitpick comments (1)
src/components/subscription-plans/blocks/subscription-plan-link.tsx (1)
138-138: Improve currency display formatting.The raw BigNumber string output lacks proper currency formatting. Consider formatting for better user experience:
-{totalAmount.toString()} {displayCurrency} total +{Number(totalAmount.toString()).toLocaleString()} {displayCurrency} total
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
src/components/batch-payout.tsx(1 hunks)src/components/dashboard/blocks/invoice-row.tsx(1 hunks)src/components/dashboard/invoices-received.tsx(2 hunks)src/components/dashboard/invoices-sent.tsx(1 hunks)src/components/dashboard/subscriptions.tsx(3 hunks)src/components/subscription-plans/blocks/payments-table.tsx(1 hunks)src/components/subscription-plans/blocks/subscribers-table.tsx(1 hunks)src/components/subscription-plans/blocks/subscription-plan-link.tsx(5 hunks)src/components/ui/table/error-state.tsx(1 hunks)src/components/ui/table/table-head-cell.tsx(1 hunks)src/components/ui/table/table.tsx(9 hunks)src/components/view-recurring-payments/view-recurring-payments.tsx(2 hunks)
✅ Files skipped from review due to trivial changes (6)
- src/components/batch-payout.tsx
- src/components/dashboard/invoices-received.tsx
- src/components/dashboard/blocks/invoice-row.tsx
- src/components/dashboard/invoices-sent.tsx
- src/components/ui/table/table-head-cell.tsx
- src/components/ui/table/table.tsx
🚧 Files skipped from review as they are similar to previous changes (3)
- src/components/dashboard/subscriptions.tsx
- src/components/subscription-plans/blocks/subscribers-table.tsx
- src/components/view-recurring-payments/view-recurring-payments.tsx
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#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.
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
src/components/subscription-plans/blocks/subscription-plan-link.tsx (13)
Learnt from: bassgeta
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.
Learnt from: aimensahnoun
PR: #82
File: src/components/create-recurring-payment/blocks/create-recurring-payment-form.tsx:131-131
Timestamp: 2025-07-11T11:17:32.659Z
Learning: In the RequestNetwork/easy-invoice codebase, the user aimensahnoun prefers to keep recurring payment functionality limited to Sepolia only. Hardcoding the chain to "sepolia" in recurring payment components is intentional and acceptable, rather than making it dynamic based on the connected network.
Learnt from: rodrigopavezi
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
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.
Learnt from: aimensahnoun
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.
Learnt from: rodrigopavezi
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.
Learnt from: aimensahnoun
PR: #8
File: src/app/invoice-me/page.tsx:21-21
Timestamp: 2025-02-14T12:48:42.125Z
Learning: In the easy-invoice codebase, error handling for TRPC queries is not required at the component level as confirmed by the maintainer.
Learnt from: bassgeta
PR: #82
File: src/server/routers/recurring-payment.ts:143-148
Timestamp: 2025-07-11T12:56:11.332Z
Learning: The v2/payouts/recurring/{externalPaymentId} PATCH endpoint in the RequestNetwork/easy-invoice project specifically returns a 200 status code on success or an error status code - it does not return other 2xx success codes like 201 or 204. The status check response.status !== 200 is correct for this specific endpoint.
Learnt from: aimensahnoun
PR: #21
File: src/app/invoices/[ID]/page.tsx:113-148
Timestamp: 2025-02-20T10:27:02.993Z
Learning: The easy-invoice project prefers simpler, direct implementations over abstract utilities. For example, using .toFixed(2) directly instead of creating separate number formatting utilities.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_messy_silver_fox.sql:1-12
Timestamp: 2025-07-14T14:17:05.340Z
Learning: In the RequestNetwork/easy-invoice codebase, monetary amounts are stored as text in the database schema rather than numeric types. This is a deliberate architectural decision to maintain consistency across all amount fields in the system.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: MantisClone
PR: #59
File: src/app/api/webhook/route.ts:77-95
Timestamp: 2025-05-22T18:19:12.366Z
Learning: For webhook handlers in the Easy Invoice project, unknown or unexpected subStatus values in payment processing should be treated as errors (using console.error) rather than warnings, and should return a 422 Unprocessable Entity status code.
src/components/subscription-plans/blocks/payments-table.tsx (7)
Learnt from: rodrigopavezi
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.
Learnt from: aimensahnoun
PR: #2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Learnt from: aimensahnoun
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.
Learnt from: aimensahnoun
PR: #8
File: src/app/invoice-me/page.tsx:21-21
Timestamp: 2025-02-14T12:48:42.125Z
Learning: In the easy-invoice codebase, error handling for TRPC queries is not required at the component level as confirmed by the maintainer.
Learnt from: bassgeta
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.
Learnt from: bassgeta
PR: #91
File: drizzle/0007_messy_silver_fox.sql:1-12
Timestamp: 2025-07-14T14:17:05.340Z
Learning: In the RequestNetwork/easy-invoice codebase, monetary amounts are stored as text in the database schema rather than numeric types. This is a deliberate architectural decision to maintain consistency across all amount fields in the system.
Learnt from: aimensahnoun
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.
🧬 Code Graph Analysis (2)
src/components/ui/table/error-state.tsx (2)
src/components/ui/card.tsx (2)
Card(79-79)CardContent(79-79)src/components/ui/button.tsx (1)
Button(56-56)
src/components/subscription-plans/blocks/payments-table.tsx (8)
src/lib/types/index.ts (1)
SubscriptionPayment(22-33)src/server/db/schema.ts (1)
SubscriptionPlan(390-390)src/components/ui/table/table-head-cell.tsx (1)
TableHeadCell(9-13)src/lib/constants/currencies.ts (1)
formatCurrencyLabel(94-139)src/components/short-address.tsx (1)
ShortAddress(12-37)src/components/ui/table/error-state.tsx (1)
ErrorState(12-44)src/components/ui/table/empty-state.tsx (1)
EmptyState(10-24)src/components/ui/table/pagination.tsx (1)
Pagination(10-45)
⏰ 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 (5)
src/components/ui/table/error-state.tsx (1)
1-44: LGTM! Well-designed reusable error state component.This is a clean, reusable UI component that provides consistent error handling across the application. The implementation includes proper loading states, accessibility considerations, and follows good design patterns with clear visual hierarchy.
src/components/subscription-plans/blocks/subscription-plan-link.tsx (2)
31-31: Good hydration handling for Next.js.The mounted state pattern properly addresses SSR/client hydration mismatches when accessing
window.location.origin.Also applies to: 37-39
20-20: Excellent fix for financial calculation precision.The BigNumber implementation properly addresses floating-point precision issues in financial calculations. This prevents accumulation of rounding errors that could occur with JavaScript's native number arithmetic.
Also applies to: 64-73
src/components/subscription-plans/blocks/payments-table.tsx (2)
103-107: Excellent polling implementation for real-time updates.The 3-second polling with
refetchOnMount: trueensures users see fresh payment data, addressing the real-time update concern mentioned in the PR objectives. This maintains consistency with other components in the application.
109-131: Comprehensive error handling with good UX.The error state provides meaningful feedback with retry functionality while showing placeholder stat cards. The user experience remains consistent even during failures.
…lan if cancelling any payments fails
src/components/view-recurring-payments/view-recurring-payments.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
We should display the number of past payments and number of remaining payments on all Subscription-related tables including:
- Subscriptions (Dashboard)
- Subscribers Table
- Subscription Payments Table
- Subscription Plans - show the total number of payments in the subscription plan.
Take inspiration from the Recurring Payments table on the Payouts Page where we already show the "Total Payments" and "Current Payments" for each recurring payment.
MantisClone
left a comment
MantisClone
left a comment
There was a problem hiding this comment.
Partial Review 🚧 not quite done yet. Sorry.
…ndling and a global 404 page
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/server/routers/subscription-plan.ts (2)
91-126: LGTM! Efficient subscriber retrieval query.The query properly filters for active plans and non-cancelled payments, with efficient early returns and column selection. The logic flow is well-structured.
For users with many subscription plans, consider adding pagination or limiting results to improve performance.
127-182: LGTM! Complex payment transformation logic.The query correctly retrieves and transforms payment data across all subscription plans. The reduce function properly flattens the nested structure and handles edge cases well.
Consider extracting the payment transformation logic (lines 162-180) into a separate utility function to improve readability and testability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/app/i/[id]/page.tsx(1 hunks)src/app/not-found.tsx(1 hunks)src/app/s/[id]/helpers.ts(1 hunks)src/app/s/[id]/page.tsx(2 hunks)src/lib/utils.ts(2 hunks)src/server/routers/subscription-plan.ts(5 hunks)
✅ Files skipped from review due to trivial changes (2)
- src/app/i/[id]/page.tsx
- src/app/not-found.tsx
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#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.
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
📚 Learning: the `v2/payouts/recurring/{externalpaymentid}` patch endpoint in the requestnetwork/easy-invoice pro...
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#82
File: src/server/routers/recurring-payment.ts:143-148
Timestamp: 2025-07-11T12:56:11.332Z
Learning: The `v2/payouts/recurring/{externalPaymentId}` PATCH endpoint in the RequestNetwork/easy-invoice project specifically returns a 200 status code on success or an error status code - it does not return other 2xx success codes like 201 or 204. The status check `response.status !== 200` is correct for this specific endpoint.
Applied to files:
src/lib/utils.ts
📚 Learning: in the easy-invoice codebase, error handling for trpc queries is not required at the component level...
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#8
File: src/app/invoice-me/page.tsx:21-21
Timestamp: 2025-02-14T12:48:42.125Z
Learning: In the easy-invoice codebase, error handling for TRPC queries is not required at the component level as confirmed by the maintainer.
Applied to files:
src/lib/utils.ts
📚 Learning: for webhook handlers in the easy invoice project, unknown or unexpected substatus values in payment ...
Learnt from: MantisClone
PR: RequestNetwork/easy-invoice#59
File: src/app/api/webhook/route.ts:77-95
Timestamp: 2025-05-22T18:19:12.366Z
Learning: For webhook handlers in the Easy Invoice project, unknown or unexpected subStatus values in payment processing should be treated as errors (using console.error) rather than warnings, and should return a 422 Unprocessable Entity status code.
Applied to files:
src/lib/utils.ts
📚 Learning: the handleformsubmit function in src/components/invoice-form.tsx correctly uses data.clientemail fro...
Learnt from: rodrigopavezi
PR: RequestNetwork/easy-invoice#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/s/[id]/page.tsx
📚 Learning: the payrequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicp...
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
Applied to files:
src/server/routers/subscription-plan.ts
📚 Learning: in the requestnetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type ...
Learnt from: bassgeta
PR: RequestNetwork/easy-invoice#91
File: drizzle/0007_awesome_gertrude_yorkes.sql:8-8
Timestamp: 2025-07-14T14:29:03.237Z
Learning: In the RequestNetwork/easy-invoice codebase, database migration 006 creates the frequency_enum type that migration 007 references for the subscription plans table. The migration dependencies are properly structured with foundational types created in earlier migrations.
Applied to files:
src/server/routers/subscription-plan.ts
📚 Learning: in `src/server/routers/payment.ts`, the batchpay input validation already handles empty arrays corre...
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#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/server/routers/subscription-plan.ts
🧬 Code Graph Analysis (3)
src/app/s/[id]/page.tsx (2)
src/server/auth/index.ts (1)
getCurrentSession(96-103)src/app/s/[id]/helpers.ts (1)
getSubscriptionPlan(4-13)
src/app/s/[id]/helpers.ts (1)
src/lib/utils.ts (1)
isNotFoundError(34-40)
src/server/routers/subscription-plan.ts (4)
src/server/db/schema.ts (2)
subscriptionPlanTable(283-300)recurringPaymentTable(218-257)src/server/db/index.ts (1)
db(10-12)src/server/trpc.ts (1)
protectedProcedure(39-39)src/lib/types/index.ts (1)
SubscriptionPayment(22-33)
⏰ 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 (9)
src/lib/utils.ts (2)
30-32: LGTM! Improved logic for payment cancellation.The simplified approach using exclusion logic (
status !== "cancelled" && status !== "completed") is more maintainable than maintaining a whitelist of cancellable statuses. This makes the code more resilient to future payment status additions.
34-40: LGTM! Well-implemented error type guard.The function properly handles the nested TRPC error structure and provides type-safe error classification. The thorough type checking with
instanceofensures robust error detection.src/app/s/[id]/helpers.ts (1)
4-13: LGTM! Well-structured helper with proper error handling.The function properly centralizes subscription plan fetching logic and implements graceful error handling by returning
nullfor "not found" cases while re-throwing unexpected errors. The use of theisNotFoundErrorutility enhances code readability and type safety.src/app/s/[id]/page.tsx (2)
20-22: LGTM! Good security practice.Adding authentication check and redirecting unauthenticated users appropriately secures the subscription plan viewing functionality.
23-23: LGTM! Improved code organization.Replacing the direct API call with the centralized
getSubscriptionPlanhelper improves code organization and provides consistent error handling across the application.src/server/routers/subscription-plan.ts (4)
34-37: LGTM! Proper soft deletion implementation.Adding the
activeflag filter implements soft deletion correctly, hiding deactivated plans while preserving data integrity.
49-58: LGTM! Excellent soft deletion implementation.Replacing hard deletion with setting the
activeflag tofalsepreserves data integrity and maintains referential relationships. The clear comment documents the behavior change well.
60-90: LGTM! Well-structured protected query.The implementation properly filters for active plans, includes necessary user relations with efficient column selection, and throws appropriate NOT_FOUND errors. The error handling aligns well with the frontend helper function usage.
188-207: LGTM! Consistent filtering implementation.The addition of active plan filtering and exclusion of cancelled payments maintains consistency with the soft deletion pattern implemented throughout the router.
…te text and no trial period in the link list
…x display of amount per cycle in subscription plan link
… prefill with connected address
…ing payments component, reword the UI terminology from recurring payment to recurring payout
MantisClone
left a comment
MantisClone
left a comment
There was a problem hiding this comment.
Nice work! Thank you for bearing with all my comments.
Changes
SubscriptionsPage, using composition.confirmMessageprop fromuseCancelRecurringPaymenthook.payerto therecurringPaymententity (forgot to do it before 🤦 ), required since recurring payments can't be craeted without a payer address.activeflag to the subscription plan entity so we can hide it and not remove it.subscriptionId.notFoundhelper, currently only works for the subscription plan preview page.Testing
Resolves #95
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Database