Open
Conversation
This avoids loading the tx inputs where they are unlikely needed. Can still be requested by passing`includeInputs=true` to the query. The following api endpoints are affected: - /api/payments - /api/paybutton/transactions/[id] None of these needs the inputs by default.
This just add overhead, especially when called in loops.
This is called from the very niche endpoint /api/transaction/years. The amount > 0 was intended to only check for payments, but in practice this doesn't matter. We can just return the years of acticity for this userId and show no payments for the years it was not used on paybutton. This dramatically speeds up the query (from ~9s to ~100ms on my machine).
This makes the payment requests much faster.
This speeds up loading of the payments page for some filters.
Contributor
📝 WalkthroughWalkthroughThis PR extends the transaction and payment handling pipeline by introducing an Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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}
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
pages/payments/index.tsx (1)
238-244:⚠️ Potential issue | 🟡 MinorDebug logging may fail due to stream consumption order.
When
paymentsResponse.okis false, calling bothpaymentsResponse.body(line 241) andpaymentsResponse.json()(line 242) can cause issues sincebodyis a ReadableStream that can only be consumed once. The.json()call may fail or return incomplete data.Consider simplifying the error logging:
🔧 Suggested fix
if (!paymentsResponse.ok || !paymentsCountResponse.ok) { - console.log('paymentsResponse status', paymentsResponse.status) - console.log('paymentsResponse status text', paymentsResponse.statusText) - console.log('paymentsResponse body', paymentsResponse.body) - console.log('paymentsResponse json', await paymentsResponse.json()) + console.log('paymentsResponse failed:', paymentsResponse.status, paymentsResponse.statusText) + console.log('paymentsCountResponse failed:', paymentsCountResponse.status, paymentsCountResponse.statusText) throw new Error('Failed to fetch payments or count') }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pages/payments/index.tsx` around lines 238 - 244, The debug logging reads paymentsResponse.body and then paymentsResponse.json(), which can consume the response stream twice and fail; update the error logging in the failure branch (where paymentsResponse and paymentsCountResponse are checked) to avoid double-consuming the stream—either remove the paymentsResponse.body access and only await paymentsResponse.json(), or call paymentsResponse.clone().json() for logging (or use text() once) so the original response stream isn't consumed twice; apply the same approach if you need to inspect paymentsCountResponse.services/transactionService.ts (1)
576-585:⚠️ Potential issue | 🟡 MinorUse
Number(tx.amount) > 0for consistency with amount comparisons elsewhere.Line 582 compares
tx.amount > 0directly, but line 1098 in the same file explicitly converts the amount to a number before comparing:Number(tx.amount) > 0. Sincetx.amountis aPrisma.Decimal, follow the established pattern in this codebase and use the explicit conversion for clarity and consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@services/transactionService.ts` around lines 576 - 585, The isPayment calculation in the flatTxData mapping uses tx.amount > 0; update it to use Number(tx.amount) > 0 to match the established pattern and handle Prisma.Decimal consistently—locate the flatTxData const and change the isPayment expression from tx.amount > 0 to Number(tx.amount) > 0 (transactionsData and tx.amount are the referenced symbols).
🧹 Nitpick comments (1)
prisma-local/migrations/20260228000000_add_is_payment_flag/migration.sql (1)
1-8: Migration is correct; consider operational impact for large tables.The backfill logic (
amount > 0) correctly matches the application code increateManyTransactions(line 582 of transactionService.ts) andchronikService.ts(line 301).For production deployment on large Transaction tables, be aware that the
UPDATEandCREATE INDEXstatements may lock the table or cause significant I/O. Consider running during low-traffic periods or using online DDL strategies if supported by your MySQL version.,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@prisma-local/migrations/20260228000000_add_is_payment_flag/migration.sql` around lines 1 - 8, The migration's UPDATE and CREATE INDEX can cause locks/IO on large Transaction tables; modify migration.sql to perform the backfill in safe steps (batch the UPDATE to set isPayment where amount>0 in bounded chunks until complete) and create the index using an online DDL option if supported (e.g., ALTER/CREATE INDEX with ALGORITHM=INPLACE, LOCK=NONE) or document that it must be run during a low-traffic maintenance window; note that this change corresponds to the new isPayment column and backfill in migration.sql and is logically tied to the application logic in transactionService.ts (createManyTransactions) and chronikService.ts.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@pages/payments/index.tsx`:
- Around line 238-244: The debug logging reads paymentsResponse.body and then
paymentsResponse.json(), which can consume the response stream twice and fail;
update the error logging in the failure branch (where paymentsResponse and
paymentsCountResponse are checked) to avoid double-consuming the stream—either
remove the paymentsResponse.body access and only await paymentsResponse.json(),
or call paymentsResponse.clone().json() for logging (or use text() once) so the
original response stream isn't consumed twice; apply the same approach if you
need to inspect paymentsCountResponse.
In `@services/transactionService.ts`:
- Around line 576-585: The isPayment calculation in the flatTxData mapping uses
tx.amount > 0; update it to use Number(tx.amount) > 0 to match the established
pattern and handle Prisma.Decimal consistently—locate the flatTxData const and
change the isPayment expression from tx.amount > 0 to Number(tx.amount) > 0
(transactionsData and tx.amount are the referenced symbols).
---
Nitpick comments:
In `@prisma-local/migrations/20260228000000_add_is_payment_flag/migration.sql`:
- Around line 1-8: The migration's UPDATE and CREATE INDEX can cause locks/IO on
large Transaction tables; modify migration.sql to perform the backfill in safe
steps (batch the UPDATE to set isPayment where amount>0 in bounded chunks until
complete) and create the index using an online DDL option if supported (e.g.,
ALTER/CREATE INDEX with ALGORITHM=INPLACE, LOCK=NONE) or document that it must
be run during a low-traffic maintenance window; note that this change
corresponds to the new isPayment column and backfill in migration.sql and is
logically tied to the application logic in transactionService.ts
(createManyTransactions) and chronikService.ts.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3019f77f-9fec-447f-8e8b-4a22d8acd0e0
📒 Files selected for processing (8)
pages/api/paybutton/transactions/[id].tspages/api/payments/index.tspages/payments/index.tsxprisma-local/migrations/20260228000000_add_is_payment_flag/migration.sqlprisma-local/schema.prismaredis/paymentCache.tsservices/chronikService.tsservices/transactionService.ts
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.
Improve the payments page loading speed by removing the bottlenecks:
Summary by CodeRabbit
Release Notes
New Features
includeInputsparameter to transaction and payment APIs for retrieving detailed transaction input data.Performance