fix: add .catch() to promise chains - #1094
Conversation
|
Someone is attempting to deploy a commit to the Karan Mani Tripathi 's projects Team on Vercel. A member of the Team first needs to authorize it. |
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
github-actions
Bot
added
gssoc'26
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughThe change specifies radix 10 for parsing the analytics date range, doubt action IDs, and classroom IDs. Existing fetching, validation, authorization, response, and error-handling flows remain unchanged. ChangesNumeric parsing updates
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
codeant-ai
Bot
added
the
size:XS
|
@coderabbitai review |
github-actions
Bot
added
size/xs
and removed
size:XS
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| const end = new Date(); | ||
| const start = new Date(); | ||
| start.setDate(end.getDate() - parseInt(dateRange)); | ||
| start.setDate(end.getDate() - parseInt(dateRange, 10)); |
There was a problem hiding this comment.
Suggestion: This subtracts calendar days in local time and then sends UTC instants to an API that compares timestamps directly. Across daylight-saving transitions, the resulting window is 23 or 25 hours per day rather than exactly the selected 7, 30, or 90-day duration, causing records near the range boundary to be included or excluded unexpectedly. Compute the range using a consistent UTC duration or explicitly define the analytics window as local calendar dates. [possible bug]
Severity Level: Major ⚠️
- ⚠️ Analytics windows vary across daylight-saving transitions.
- ⚠️ Teacher reports misclassify boundary-date doubts.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/app/(routes)/dashboard/analytics/page.tsx
**Line:** 36:36
**Comment:**
*Possible Bug: This subtracts calendar days in local time and then sends UTC instants to an API that compares timestamps directly. Across daylight-saving transitions, the resulting window is 23 or 25 hours per day rather than exactly the selected 7, 30, or 90-day duration, causing records near the range boundary to be included or excluded unexpectedly. Compute the range using a consistent UTC duration or explicitly define the analytics window as local calendar dates.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
|
||
| const { id } = await params; | ||
| const doubtId = parseInt(id); | ||
| const doubtId = parseInt(id, 10); |
There was a problem hiding this comment.
Suggestion: The permissive parseInt call accepts numeric prefixes, so a request for an identifier such as 123abc is treated as an action on doubt 123. This allows malformed route parameters to invoke like, solve, or edit operations on a real doubt; validate that the entire parameter is a valid integer before converting it. [api mismatch]
Severity Level: Major ⚠️
- ❌ Malformed action URLs target unintended doubts.
- ⚠️ Like, solve, and edit operations affect wrong resources.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/app/api/doubts/action/[id]/route.ts
**Line:** 25:25
**Comment:**
*Api Mismatch: The permissive `parseInt` call accepts numeric prefixes, so a request for an identifier such as `123abc` is treated as an action on doubt `123`. This allows malformed route parameters to invoke like, solve, or edit operations on a real doubt; validate that the entire parameter is a valid integer before converting it.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
|
||
| const { id } = await params; | ||
| const doubtId = parseInt(id); | ||
| const doubtId = parseInt(id, 10); |
There was a problem hiding this comment.
Suggestion: The DELETE handler converts the route parameter to a number but never rejects NaN or other invalid values before using it in the database query. Wholly invalid IDs can therefore reach the database and produce an internal error instead of the expected 400 response, while prefixed values can target a different real doubt; apply the same strict validation used by the PATCH handler. [api mismatch]
Severity Level: Critical 🚨
- ❌ Invalid deletion requests return server errors.
- ⚠️ Prefixed IDs can delete unintended authorized doubts.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/app/api/doubts/action/[id]/route.ts
**Line:** 323:323
**Comment:**
*Api Mismatch: The DELETE handler converts the route parameter to a number but never rejects `NaN` or other invalid values before using it in the database query. Wholly invalid IDs can therefore reach the database and produce an internal error instead of the expected 400 response, while prefixed values can target a different real doubt; apply the same strict validation used by the PATCH handler.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| const user = await currentUser(); | ||
| const email = user?.primaryEmailAddress?.emailAddress ?? null; | ||
| const classroomId = classroomIdStr ? parseInt(classroomIdStr) : null; | ||
| const classroomId = classroomIdStr ? parseInt(classroomIdStr, 10) : null; |
There was a problem hiding this comment.
Suggestion: parseInt turns malformed classroom parameters such as 7abc into 7, and turns abc into NaN; the later truthiness check then either queries classroom 7 or falls through to the public-doubt query as though no classroom filter was supplied. This silently returns the wrong dataset instead of rejecting the invalid parameter, so use strict classroom-ID parsing and explicitly return a 400 error for invalid values. [incorrect condition logic]
Severity Level: Major ⚠️
- ⚠️ Classroom listings can return the wrong dataset.
- ⚠️ Invalid filters silently expose public-doubt results.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/app/api/doubts/route.ts
**Line:** 58:58
**Comment:**
*Incorrect Condition Logic: `parseInt` turns malformed classroom parameters such as `7abc` into `7`, and turns `abc` into `NaN`; the later truthiness check then either queries classroom 7 or falls through to the public-doubt query as though no classroom filter was supplied. This silently returns the wrong dataset instead of rejecting the invalid parameter, so use strict classroom-ID parsing and explicitly return a 400 error for invalid values.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix1 participant
CodeAnt-AI Description
Parse numeric IDs and analytics ranges consistently as decimal values
What Changed
Impact
✅ Reliable doubt updates and deletions✅ Correct classroom filtering✅ Accurate analytics date ranges💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit