feat(api): 근무자 API 구현 - #83
Conversation
|
Warning Review limit reached
More reviews will be available in 39 minutes and 3 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 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 credits. 🚦 How do rate 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 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 (3)
Walkthrough워커 CRUD API가 Changes워커 API 표면과 지원 코드
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 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}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/database/prisma/seed.ts (1)
104-125: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win기존 시드 DB에서 워커가 중복 생성됩니다.
Line 111의
upsert키가organizationId_employeeCode인데, 이번에employeeCode포맷을 바꾸면서 예전에W001/W002/W003로 시드된 행을 더 이상 매칭하지 못합니다. 그 상태로 시드를 다시 돌리면 기존 워커는 남고W-0001~0003가 새로 추가되어 멱등성이 깨집니다. legacy 코드를 먼저 정규화하거나 정리한 뒤 새 포맷으로upsert해야 합니다. As per path instructions, "upsert 사용으로 멱등성 보장 여부 확인"이 필요합니다.수정 예시
- await Promise.all( - [ - { employeeCode: "W-0001", name: "김민지", weeklyContractHours: 20 }, - { employeeCode: "W-0002", name: "박준호", weeklyContractHours: 24 }, - { employeeCode: "W-0003", name: "이서연", weeklyContractHours: 16 }, - ].map((worker) => - prisma.worker.upsert({ - where: { - organizationId_employeeCode: { - organizationId: organization.id, - employeeCode: worker.employeeCode, - }, - }, - update: { - name: worker.name, - weeklyContractHours: worker.weeklyContractHours, - }, - create: { - organizationId: organization.id, - employeeCode: worker.employeeCode, - name: worker.name, - weeklyContractHours: worker.weeklyContractHours, - }, - }), - ), - ); + await Promise.all( + [ + { + legacyEmployeeCode: "W001", + employeeCode: "W-0001", + name: "김민지", + weeklyContractHours: 20, + }, + { + legacyEmployeeCode: "W002", + employeeCode: "W-0002", + name: "박준호", + weeklyContractHours: 24, + }, + { + legacyEmployeeCode: "W003", + employeeCode: "W-0003", + name: "이서연", + weeklyContractHours: 16, + }, + ].map(async (worker) => { + await prisma.worker.updateMany({ + where: { + organizationId: organization.id, + employeeCode: worker.legacyEmployeeCode, + }, + data: { + employeeCode: worker.employeeCode, + }, + }); + + return prisma.worker.upsert({ + where: { + organizationId_employeeCode: { + organizationId: organization.id, + employeeCode: worker.employeeCode, + }, + }, + update: { + name: worker.name, + weeklyContractHours: worker.weeklyContractHours, + }, + create: { + organizationId: organization.id, + employeeCode: worker.employeeCode, + name: worker.name, + weeklyContractHours: worker.weeklyContractHours, + }, + }); + }), + );🤖 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 `@packages/database/prisma/seed.ts` around lines 104 - 125, The worker seeding logic in the Promise.all map uses prisma.worker.upsert with organizationId_employeeCode, but the new employeeCode format no longer matches legacy seeded rows, so rerunning the seed creates duplicates. Update the seed flow in the worker upsert block to handle existing W001/W002/W003 records first by normalizing or migrating legacy employeeCode values before inserting W-0001/W-0002/W-0003, and keep the upsert keyed on organizationId_employeeCode so the operation remains idempotent.Source: Path instructions
🤖 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 `@apps/api/test/helpers/fake-prisma.ts`:
- Around line 75-82: The fixed starting values in the fake Prisma state cause ID
sequencing to move backward when seeded data already contains larger IDs. Update
the fake state initialization in fake-prisma so nextOrganizationId, nextUserId,
nextRefreshTokenId, and nextBusinessHourId are computed from the existing seeded
records the same way nextWorkerId is, using the relevant collections to pick max
existing ID plus one. This keeps the test double aligned with Prisma’s
auto-increment behavior and avoids collisions when tests inject initial state.
In `@apps/api/test/organization.routes.test.ts`:
- Around line 129-208: Add a test case in organization.routes.test.ts for an
authenticated user whose Prisma fixture has no organization, and verify that
GET/PATCH /api/organization is rejected with the ORGANIZATION_REQUIRED error.
Reuse the existing createFakePrisma, createApp, authHeader, and organization
route request pattern so the new case clearly covers the “organization required”
access control rule and prevents regressions for users without an organization.
In `@docs/openapi.yaml`:
- Around line 624-626: The Worker.employeeCode schema is too loose because it is
only declared as a string with an example, so update the OpenAPI definition for
employeeCode in docs/openapi.yaml to enforce the W-0001-style contract by adding
an appropriate pattern (and keep the example aligned). Make the change in the
existing employeeCode property definition so Swagger/UI and generated clients
treat only the intended 사번 format as valid.
---
Outside diff comments:
In `@packages/database/prisma/seed.ts`:
- Around line 104-125: The worker seeding logic in the Promise.all map uses
prisma.worker.upsert with organizationId_employeeCode, but the new employeeCode
format no longer matches legacy seeded rows, so rerunning the seed creates
duplicates. Update the seed flow in the worker upsert block to handle existing
W001/W002/W003 records first by normalizing or migrating legacy employeeCode
values before inserting W-0001/W-0002/W-0003, and keep the upsert keyed on
organizationId_employeeCode so the operation remains idempotent.
🪄 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: 79ebe804-ae93-4f18-804a-6ab8c12e8f14
📒 Files selected for processing (13)
apps/api/src/modules/workers/workers.handlers.tsapps/api/src/modules/workers/workers.service.tsapps/api/src/routes/index.tsapps/api/src/routes/workers.routes.tsapps/api/test/auth.routes.test.tsapps/api/test/helpers/fake-prisma.tsapps/api/test/helpers/organization-fixtures.tsapps/api/test/organization.routes.test.tsapps/api/test/workers.routes.test.tsdocs/API.mddocs/openapi.yamlpackages/database/prisma/seed.tspackages/shared/src/schemas/workers.ts
|
리뷰 코멘트 처리 상태입니다.
검증:
|
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 `@apps/api/test/helpers/fake-prisma.ts`:
- Around line 233-247: The `fake-prisma.ts` sorting in the `rules.sort` callback
is using `localeCompare` for `dayOfWeek`, which sorts alphabetically instead of
Prisma Enum declaration order. Update the `dayOfWeek` branch in the
`Array.isArray(orderBy)` handling to compare against the enum’s intended order
(matching Prisma/PostgreSQL, e.g. via a fixed ordinal map), so
`staffing-rules.service.ts` tests see the same weekday ordering as production.
Keep the `startTime` ordering logic unchanged.
🪄 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: 2d95e191-3817-4013-8ac1-98d15ec55019
📒 Files selected for processing (3)
apps/api/src/routes/index.tsapps/api/test/helpers/fake-prisma.tsdocs/API.md
2 participants
개요
근무자 관리 API를 추가합니다.
Closes #77
변경 사항
/workers목록/생성/수정/삭제 API를 추가했습니다.lastWorkerSequence기반의W-0001형식으로 자동 생성합니다.404 WORKER_NOT_FOUND처리를 적용했습니다.worker_id는 null 처리되도록 검증했습니다.변경 유형
feat— 새로운 기능fix— 버그 수정refactor— 리팩터링 (기능 변경 없음)test— 테스트 코드perf— 성능 개선docs— 문서 수정chore— 빌드·설정 변경영향 범위
web—apps/webapi—apps/apidb—packages/databaseshared—packages/sharedrepo— 루트 설정·CI/CD·문서테스트 방법
pnpm --filter @fragment/api typecheckpnpm --filter @fragment/api testpnpm --filter @fragment/api lintpnpm --filter @fragment/api build체크리스트
packages/shared) 업데이트 (타입 변경 시)리뷰 포인트
W-0001사번 생성 방식과 조직별 sequence 갱신 흐름404 WORKER_NOT_FOUND로 처리하는 범위 제한W001계열) 정규화 방식Summary by CodeRabbit