fix: 참여 완료 모임 재진입 시 결과 화면 표시 - #95
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 42 minutes and 46 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Walkthrough
Changes스케줄 결과 조회 및 참여자 뷰 복원
추정 코드 리뷰 노력🎯 4 (Complex) | ⏱️ ~50 minutes 연관 PR
제안 레이블
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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: 4
🤖 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 `@src/app/api/schedules/`[id]/route.ts:
- Around line 68-89: The logic for fetching participant and schedule data is
duplicated across multiple locations in the route handler. Extract this common
pattern into a helper function that encapsulates the calls to
getScheduleParticipantForUser and getScheduleResult based on the session and
schedule ID. This helper should handle the conditional participant lookup based
on whether a session exists, returning both the participant and schedule data
together. Replace all duplicate occurrences of this pattern with calls to the
new helper function to improve maintainability and prevent inconsistencies
during future modifications.
In `@src/app/schedule/`[id]/ScheduleRoomClient.tsx:
- Around line 258-268: When the server response indicates
hasSubmittedAvailability is false, the localStorage cache (savedSubmittedName)
should be invalidated to prevent showing a result view for a submission that no
longer exists on the server. Add logic to clear or remove the saved submitted
name from localStorage when hasSubmittedAvailability is false, ensuring that the
client state stays synchronized with the server state and the localStorage cache
is only used as a temporary hint when the server confirms the submission
actually exists. This prevents the edge case where users see results but have no
way to resubmit when their data has been deleted on the server.
In `@src/lib/schedules/__tests__/store.test.ts`:
- Around line 121-148: The test for "finds a submitted participant by schedule
and user id" is missing an edge case for empty userId. Add a test assertion that
verifies the behavior of getScheduleParticipantForUser when called with an empty
string as the userId parameter (in addition to the existing "other-user" test),
ensuring the function properly handles this edge case and returns the expected
result (likely null).
In `@src/lib/schedules/store.ts`:
- Around line 147-156: The getScheduleParticipantForUser function lacks
validation for empty userId values. When userId is passed as an empty string,
the function will execute the database query with that empty value instead of
returning null early. Add a guard clause at the start of the function to check
if userId is empty or falsy, and return null immediately if so, providing
defensive validation at the store level before any database operations occur.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: e4ae2d84-1a8e-4f69-a920-8fdd9041c4ee
📒 Files selected for processing (5)
src/app/api/schedules/[id]/route.tssrc/app/api/schedules/route.tssrc/app/schedule/[id]/ScheduleRoomClient.tsxsrc/lib/schedules/__tests__/store.test.tssrc/lib/schedules/store.ts
🚀 작업 내용 (What)
📣 핵심 변경 이유 (Why)
📸 스크린샷 (Visuals, 선택)
검증
🔗 관련 이슈 (Issue)
Close #92