[WTH-434] 회비 수정사항 반영#88
Hidden character warning
Conversation
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthrough회비 납부 대상 제외 API, 거래 잔액 스냅샷 저장, 기수 참여 기반 계정 노출 제한, 거래 일시 타입 변경, 거래 정렬 기준 변경이 추가되었고 관련 테스트와 마이그레이션이 함께 수정되었습니다. Changes회비 도메인 변경
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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
🧹 Nitpick comments (1)
src/main/resources/db/migration/V9__add_account_transaction_balance_after.sql (1)
1-30: 🧹 Nitpick | 🔵 Trivial대용량 테이블 마이그레이션 시 락 영향 검토 권장.
ADD COLUMN→ 윈도우 함수UPDATE JOIN→ 추가UPDATE→MODIFY COLUMN NOT NULL로 이어지는 4단계 마이그레이션은account_transaction테이블 크기가 클 경우 처리 시간과 락 범위가 커질 수 있습니다. 운영 배포 시 저트래픽 시간대 실행이나 온라인 스키마 변경 도구 사용을 고려해보세요.🤖 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 `@src/main/resources/db/migration/V9__add_account_transaction_balance_after.sql` around lines 1 - 30, Review the V9 migration for account_transaction to account_transaction.balance_after and account_transaction.UPDATE paths: this four-step ALTER/UPDATE/MODIFY sequence can cause long locks on large tables. Adjust the migration plan to reduce operational impact by considering an online schema change approach or splitting the backfill and NOT NULL enforcement into safer deployment steps, and keep the relevant logic centered around the balance_after backfill and final NOT NULL conversion.
🤖 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/main/kotlin/com/weeth/domain/account/application/dto/request/SaveAccountTransactionRequest.kt`:
- Around line 30-31: `SaveAccountTransactionRequest`의 `transactedAt` 타입이
`LocalDateTime`으로 바뀌었으므로, `@Schema`의 설명과 예시를 이에 맞게 갱신하세요. `transactedAt` 주석에서 날짜
전용 표현을 제거하고, ISO-8601 `LocalDateTime` 형식이 드러나는 예시로 바꿔 Swagger 문서와 실제 Jackson
역직렬화 형식이 일치하도록 수정하면 됩니다.
- Line 31: `SaveAccountTransactionRequest` and the update flow use inconsistent
timestamp precision, causing `ManageAccountTransactionUseCase.update()` to
truncate update times to midnight. Update `UpdateAccountTransactionRequest` to
use `LocalDateTime` like `SaveAccountTransactionRequest`, and adjust
`ManageAccountTransactionUseCase.update()` to pass through the provided datetime
without calling `atStartOfDay()`, keeping save and update behavior aligned.
In
`@src/main/kotlin/com/weeth/domain/account/application/usecase/command/ManageAccountPaymentUseCase.kt`:
- Around line 110-113: The pre-check in ManageAccountPaymentUseCase currently
only validates paymentStatus, so targets already in EXCLUDED can slip through
because AccountPaymentTarget.exclude() resets the status to UNPAID. Update the
validation in ManageAccountPaymentUseCase to also inspect targetStatus (or an
equivalent field) before proceeding, and reject already excluded targets with
the appropriate exception/response instead of treating them as valid. Use the
existing symbols AccountPaymentTarget.exclude, AccountPaymentStatus.UNPAID, and
the target collection check in ManageAccountPaymentUseCase to place the new
guard alongside the current all-or-nothing validation.
In
`@src/main/resources/db/migration/V9__add_account_transaction_balance_after.sql`:
- Around line 4-23: The backfill in the
`V9__add_account_transaction_balance_after` migration computes `balance_after`
from `transacted_at`, but there is no separate applied/posted timestamp to
guarantee that matches the real `Account.applyTransaction()` order. Update the
migration to either derive balances from the actual apply order if such a field
exists, or explicitly document in the migration that `transactedAt` is the
source of truth and that the backfill intentionally follows that ordering. Make
sure the `UPDATE account_transaction` / running-balance logic reflects the
chosen ordering consistently.
---
Nitpick comments:
In
`@src/main/resources/db/migration/V9__add_account_transaction_balance_after.sql`:
- Around line 1-30: Review the V9 migration for account_transaction to
account_transaction.balance_after and account_transaction.UPDATE paths: this
four-step ALTER/UPDATE/MODIFY sequence can cause long locks on large tables.
Adjust the migration plan to reduce operational impact by considering an online
schema change approach or splitting the backfill and NOT NULL enforcement into
safer deployment steps, and keep the relevant logic centered around the
balance_after backfill and final NOT NULL conversion.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ea7ef56a-60b4-4883-bc17-9543b2647c6a
📒 Files selected for processing (22)
src/main/kotlin/com/weeth/domain/account/application/dto/request/ExcludePaymentTargetsRequest.ktsrc/main/kotlin/com/weeth/domain/account/application/dto/request/SaveAccountTransactionRequest.ktsrc/main/kotlin/com/weeth/domain/account/application/dto/response/AccountDashboardResponse.ktsrc/main/kotlin/com/weeth/domain/account/application/dto/response/AccountTransactionResponse.ktsrc/main/kotlin/com/weeth/domain/account/application/mapper/AccountDashboardMapper.ktsrc/main/kotlin/com/weeth/domain/account/application/mapper/AccountTransactionMapper.ktsrc/main/kotlin/com/weeth/domain/account/application/usecase/MemberAccountAccessResolver.ktsrc/main/kotlin/com/weeth/domain/account/application/usecase/command/ManageAccountPaymentUseCase.ktsrc/main/kotlin/com/weeth/domain/account/application/usecase/query/GetMyAccountQueryService.ktsrc/main/kotlin/com/weeth/domain/account/domain/entity/Account.ktsrc/main/kotlin/com/weeth/domain/account/domain/entity/AccountTransaction.ktsrc/main/kotlin/com/weeth/domain/account/presentation/AccountManageController.ktsrc/main/kotlin/com/weeth/domain/account/presentation/AccountResponseCode.ktsrc/main/resources/db/migration/V9__add_account_transaction_balance_after.sqlsrc/test/kotlin/com/weeth/domain/account/application/dto/request/AccountTransactionRequestValidationTest.ktsrc/test/kotlin/com/weeth/domain/account/application/usecase/command/ManageAccountPaymentUseCaseTest.ktsrc/test/kotlin/com/weeth/domain/account/application/usecase/command/ManageAccountTransactionUseCaseTest.ktsrc/test/kotlin/com/weeth/domain/account/application/usecase/query/GetAccountTransactionQueryServiceTest.ktsrc/test/kotlin/com/weeth/domain/account/application/usecase/query/GetMyAccountQueryServiceTest.ktsrc/test/kotlin/com/weeth/domain/account/application/usecase/query/GetMyAccountTransactionQueryServiceTest.ktsrc/test/kotlin/com/weeth/domain/account/domain/entity/AccountTest.ktsrc/test/kotlin/com/weeth/domain/account/domain/repository/AccountRepositoryTest.kt
soo0711
left a comment
There was a problem hiding this comment.
수고하셨습니다!! 코드래빗 리뷰만 참고하면 될 것 같아용
그리구 저도 거래내역을 받을 땐 날짜만 받는게 더 자연스러워보입니닷.. 정렬은 유진님이 말씀하신 것처럼 거래일자 DESC → 등록시각 DESC가 어떨까욤
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/main/kotlin/com/weeth/domain/account/application/dto/request/AccountTransactionSort.kt (2)
18-21: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value정렬 옵션별 보조키 전략 불일치
LATEST/OLDEST는createdAt을 보조키로 쓰지만,AMOUNT_DESC/AMOUNT_ASC는 여전히"id"를 보조키로 사용합니다. 동일 파일 내에서 안정 정렬 전략이 일관되지 않아 유지보수 시 혼란을 줄 수 있습니다.🤖 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 `@src/main/kotlin/com/weeth/domain/account/application/dto/request/AccountTransactionSort.kt` around lines 18 - 21, 정렬 옵션별 보조키 전략이 `AccountTransactionSort`에서 일관되지 않게 섞여 있습니다. `LATEST`/`OLDEST`와 같은 안정 정렬 기준에 맞춰 `AMOUNT_DESC`/`AMOUNT_ASC`도 동일한 보조키 전략을 사용하도록 정리하고, `Sort.by(...)` 및 `Sort.Order...`를 정의한 `AccountTransactionSort` enum의 각 케이스가 같은 기준으로 정렬되도록 수정하세요.
6-7: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win
LATEST/OLDEST는 마지막 tie-breaker에id를 넣는 편이 안전합니다
createdAt은 같은 시각에 충돌할 수 있어 페이지 순서가 흔들릴 수 있습니다.transactedAt, createdAt, id로 맞추거나, 현재 인덱스(transactedAt, account_transaction_id)에 맞춰transactedAt, id로 정렬을 맞추는 쪽이 더 낫습니다.🤖 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 `@src/main/kotlin/com/weeth/domain/account/application/dto/request/AccountTransactionSort.kt` around lines 6 - 7, The sorting strategy in AccountTransactionSort should use a stable final tie-breaker instead of relying on createdAt, which can collide for records created at the same time. Update the LATEST/OLDEST ordering to end with id, or align it with the existing account transaction index by sorting with transactedAt and id; make the change in AccountTransactionSort so paging remains deterministic.
🤖 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
`@src/main/kotlin/com/weeth/domain/account/application/dto/request/AccountTransactionSort.kt`:
- Around line 18-21: 정렬 옵션별 보조키 전략이 `AccountTransactionSort`에서 일관되지 않게 섞여 있습니다.
`LATEST`/`OLDEST`와 같은 안정 정렬 기준에 맞춰 `AMOUNT_DESC`/`AMOUNT_ASC`도 동일한 보조키 전략을 사용하도록
정리하고, `Sort.by(...)` 및 `Sort.Order...`를 정의한 `AccountTransactionSort` enum의 각
케이스가 같은 기준으로 정렬되도록 수정하세요.
- Around line 6-7: The sorting strategy in AccountTransactionSort should use a
stable final tie-breaker instead of relying on createdAt, which can collide for
records created at the same time. Update the LATEST/OLDEST ordering to end with
id, or align it with the existing account transaction index by sorting with
transactedAt and id; make the change in AccountTransactionSort so paging remains
deterministic.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 477dfe8b-ef9b-46f2-890d-329285013c61
📒 Files selected for processing (4)
src/main/kotlin/com/weeth/domain/account/application/dto/request/AccountTransactionSort.ktsrc/main/kotlin/com/weeth/domain/account/application/dto/response/AccountTransactionResponse.ktsrc/main/kotlin/com/weeth/domain/account/application/mapper/AccountTransactionMapper.ktsrc/test/kotlin/com/weeth/domain/account/application/usecase/query/GetAccountTransactionQueryServiceTest.kt
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/kotlin/com/weeth/domain/account/application/mapper/AccountTransactionMapper.kt
- src/test/kotlin/com/weeth/domain/account/application/usecase/query/GetAccountTransactionQueryServiceTest.kt
|
거래내역 일자는 원복했습니당 그냥 일자만 받도록 |
📌 Summary
급한 수정사항 반영했습니다.
📝 Changes
What
회비 QA에서 나온 백엔드 반영 사항입니다.
Why
How
📸 Screenshots / Logs
💡 Reviewer 참고사항
아 근데 생각해보니 거래일자를 받을 때 시간까지 받긴 좀 그런데.. 어떻게 하는게 좋을까요?
✅ Checklist
Summary by CodeRabbit