[fix] add webhook for verifyPayment failure#431
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughPayment fulfillment is centralized behind ChangesPayment Fulfillment Consolidation
Pro Community Page Migration
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
apps/web/src/app/(main)/dashboard/pro/community/page.tsxOops! Something went wrong! :( ESLint: 8.57.1 TypeError: Converting circular structure to JSON apps/web/src/components/payment/PaymentFlow.tsxOops! Something went wrong! :( ESLint: 8.57.1 TypeError: Converting circular structure to JSON 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
apps/api/src/services/payment.service.ts (1)
396-400: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffAvoid
anyin the return type; prefer Prisma-generated types.
paymentandsubscriptionare typed asany, which erases type safety on the payment path. Prefer the PrismaPayment/Subscriptionmodel types (or a narrowed shape). This matches the existinganypattern increatePaymentRecord/createSubscription, so tightening those together would be ideal.As per coding guidelines: "Avoid
anytype; useunknownfor truly dynamic data and narrow with type guards".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/api/src/services/payment.service.ts` around lines 396 - 400, The fulfillPayment return type currently uses any for payment and subscription, which removes type safety; update the fulfillPayment signature to use Prisma-generated Payment and Subscription types or a narrowed explicit shape instead. Locate the fulfillPayment method in PaymentService and tighten its return type, then align createPaymentRecord and createSubscription as needed so the values they return are typed consistently without any.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/api/src/services/payment.service.ts`:
- Around line 419-423: The premium email send result is being ignored in payment
handling, so a false return from sendPremiumSubscriptionEmail is still treated
as success. Update the payment flow in payment.service.ts to use the
Promise<boolean> returned by emailService.sendPremiumSubscriptionEmail and
assign emailSent based on that boolean rather than hard-setting it to true. Keep
the logic in the same subscription-email block so soft failures are reflected
correctly in the final emailSent state.
- Around line 403-458: The confirmation email in fulfillPayment is being sent
whenever sendConfirmationEmail is true, even when createPaymentRecord and
createSubscription return existing rows for the same Razorpay payment. Update
those helpers to surface whether a payment/subscription was newly created or
already existed, then gate the sendPremiumSubscriptionEmail call in
paymentService so it only runs on the first successful fulfillment; use the
existing symbols createPaymentRecord, createSubscription, fulfillPayment, and
sendPremiumSubscriptionEmail to wire the first-time-only check.
In `@apps/web/src/app/`(main)/dashboard/pro/community/page.tsx:
- Around line 9-23: The ProCommunityPage component is reading useSearchParams()
at the top level without a Suspense ancestor, which can trigger a
static-rendering bailout. Move the search-param-dependent state initialization
into a child component that uses useSearchParams, and wrap that child in a
<Suspense> boundary from ProCommunityPage so the dashboard page can render
safely.
In `@apps/web/src/components/payment/PaymentFlow.tsx`:
- Around line 123-125: The alert in PaymentFlow is shown for both transient
delays and hard failures, which can mislead users. Update the catch path around
the payment verification flow in PaymentFlow.tsx so the “access will be
activated within 2 mins” message is only shown when the failure is a confirmed
temporary delay, and use a different handling path for genuine errors. Use the
existing payment verification logic and error handling in PaymentFlow to branch
on the failure type before calling alert.
---
Nitpick comments:
In `@apps/api/src/services/payment.service.ts`:
- Around line 396-400: The fulfillPayment return type currently uses any for
payment and subscription, which removes type safety; update the fulfillPayment
signature to use Prisma-generated Payment and Subscription types or a narrowed
explicit shape instead. Locate the fulfillPayment method in PaymentService and
tighten its return type, then align createPaymentRecord and createSubscription
as needed so the values they return are typed consistently without any.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 978b4b21-4cfa-408b-932f-c752dde950f5
📒 Files selected for processing (7)
apps/api/src/index.tsapps/api/src/routers/payment.tsapps/api/src/services/payment.service.tsapps/web/src/app/(main)/dashboard/account/page.tsxapps/web/src/app/(main)/dashboard/pro/community/page.tsxapps/web/src/components/dashboard/Sidebar.tsxapps/web/src/components/payment/PaymentFlow.tsx
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/api/src/services/payment.service.ts (1)
102-110: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace
anywith concrete Prisma types.
paymentandsubscriptionhere (and thefulfillPaymentreturn type at Lines 419-420) areany, so callers lose type safety on the returned records. Since these wrap Prisma model rows, use the generatedPayment/Subscriptiontypes from@prisma/client.♻️ Proposed change
+import type { Payment, Subscription } from "`@prisma/client`"; + interface PaymentRecordResult { - payment: any; + payment: Payment; wasCreated: boolean; } interface SubscriptionResult { - subscription: any; + subscription: Subscription; wasCreated: boolean; }As per coding guidelines: "Avoid
anytype; useunknownfor truly dynamic data and narrow with type guards."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/api/src/services/payment.service.ts` around lines 102 - 110, The `PaymentRecordResult` and `SubscriptionResult` interfaces currently use `any`, which removes type safety from `payment` and `subscription` values returned by `payment.service.ts`. Update these result types, and the `fulfillPayment` return type that also exposes these records, to use the concrete Prisma model types imported from `@prisma/client` (for example `Payment` and `Subscription`) so callers get proper compile-time typing.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@apps/api/src/services/payment.service.ts`:
- Around line 102-110: The `PaymentRecordResult` and `SubscriptionResult`
interfaces currently use `any`, which removes type safety from `payment` and
`subscription` values returned by `payment.service.ts`. Update these result
types, and the `fulfillPayment` return type that also exposes these records, to
use the concrete Prisma model types imported from `@prisma/client` (for example
`Payment` and `Subscription`) so callers get proper compile-time typing.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 08cc553b-22b9-4637-aa30-f6393ac12d94
📒 Files selected for processing (3)
apps/api/src/services/payment.service.tsapps/web/src/app/(main)/dashboard/pro/community/page.tsxapps/web/src/components/payment/PaymentFlow.tsx
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/web/src/components/payment/PaymentFlow.tsx
- apps/web/src/app/(main)/dashboard/pro/community/page.tsx
1 participant
fixes: #430
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
UX Updates