fix: prevent infinite retries on auto-graded assessments#308
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe ChangesSubmission Resubmission Prevention
Poem
🎯 3 (Moderate) | ⏱️ ~15 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@server/src/module/student/student.service.ts`:
- Around line 252-266: The pre-check using prisma.roundSubmission.findUnique and
the subsequent prisma.roundSubmission.upsert are vulnerable to TOCTOU race
conditions; make the “not already COMPLETED” guard atomic by moving the check
into the write transaction. Replace the separate findUnique + upsert flow with a
transaction that first attempts a conditional update (e.g.,
prisma.roundSubmission.updateMany({ where: { applicationId, roundId, status: {
not: "COMPLETED" } }, data: { ...changes } }) and inspects the count) and if the
update affected 0 rows then either throw if a COMPLETED row exists or create the
submission via create inside the same transaction; reference
prisma.roundSubmission.findUnique, prisma.roundSubmission.updateMany / create,
applicationId_roundId, and the existingSubmission logic to implement this atomic
guarded write.
🪄 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: e534f442-a9d8-47a9-872a-2ac4ca88a136
⛔ Files ignored due to path filters (1)
client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (1)
server/src/module/student/student.service.ts
|
Hi @Sachinchaurasiya360 . Also, could u please add GSSoC labels so that it will help in my contribution points. |
|
Hi @Sachinchaurasiya360 . |
This pull request addresses a critical logic loophole in the submitRound endpoint that allowed students to infinitely resubmit answers for auto-graded assessments and overwrite their scores to achieve 100%.
Previously, the student.service.ts used Prisma's upsert method without verifying if the existing roundSubmission was already marked as COMPLETED.
Changes Made:
Fetched the existingSubmission state concurrently within the existing Promise.all block (zero performance penalty).
Added a strict validation check:
if (existingSubmission && existingSubmission.status === "COMPLETED")to block multiple submissions.Safely throws a descriptive Error
("You have already submitted this assessment.")to halt the process, fully closing the loophole.Closes #303
Summary by CodeRabbit