[ysw789]

근무자 목록이 이름 오름차순인데 커서는 생성 시각 내림차순을 사용하여, 두 명을 pageSize=1로 조회하면 첫 페이지 뒤 다음 페이지가 비고 두 번째 근무자가 누락됐습니다. worker 세 조회의 커서를 기존 이름/id 정렬과 일치시킵니다.

• manager 근무자, app 근무자, 교환 후보의 기존 name ASC/id ASC를 유지하고 같은 업장 cursor anchor의 이름을 scalar subquery로 비교합니다. opaque CursorDto의 id/createdAt 형태, 필터·건수·권한·활성/퇴사 예외·후보 시간 충돌은 보존합니다.
• decoded cursor의 필수 id/createdAt 누락은 해당 세 경로에서 기존 INVALID_CURSOR(400/B005)로 거부하고 Swagger에 명시합니다. 변경 전 H2의 createdAt 누락은 NPE였고, 이 보완은 명시적인 400 계약 변화입니다. 유효 커서의 형식은 그대로입니다.
• ManagerUser 커서 두 경로, 유스케이스/공유 DTO/decoder/handler·ErrorCode·설정은 수정하지 않습니다. 새 추상화·운영 불변식·마이그레이션은 없습니다.

검증: 실제 H2 pagination/scope Red6, 필수 cursor 필드 추가 Red3 → 관련14 Green. 최종 JAVA_TOOL_OPTIONS=-Dapi.version=1.44 ./gradlew clean build 530건 통과(실패/오류/skip0,44s). 동명이름 tie, 이름/id와 불일치한 생성 시각, 다른 업장 anchor, 필터/count/owner 및 기존 후보 self/다른 업장 충돌 제외를 확인했습니다.

독립 HTTP phase1은 원래 여섯 QA의 서버 경로를 base 소스에서 검증하면서 manager 다중 페이지 누락을 발견했습니다. 이 발견으로 최초 무변경/no-PR 판정을 취소했습니다. 최종 소스의 phase2는 커서 세 경로와 관련 필터·권한·문서만 재검증했으며, 과거 여섯 업무 흐름을 모두 최종 revision에서 재실행한 결과는 아닙니다.

최종 독립 HTTP에서 pageSize 1/2의 여섯 traversal 모두 누락·중복 없이 완료했습니다. manager/app 근무자는 각각 IDs [2,3,4,5,1]/count5, 후보는 [2,3,5]/count3, 마지막은 200 빈 목록입니다. 이름순·동명이름 ID tie·생성 시각 역전과 opaque 키 id/createdAt만을 확인했습니다. 필수 커서 값 누락 6건은 400/B005, 다른 업장 cursor 3건은 200 빈 목록/count 유지였습니다. 근무자의 활성 상태는 ACTIVATED이며 UserStatus.ACTIVE와 구분합니다. 활성·퇴사 명시/퇴사일 이력·이름 필터 계약을 보존했습니다.

비소유 사장님은 기존 200/count0/빈 목록, APP 비소속 업장은 403/A002, 비소속 후보는 400/B001, APP의 manager route는 403/A002, 무인증은 401/A001을 확인했습니다. 실제 OpenAPI 세 method의 400/B005 설명, GET 전후 업무 DB digest와 소스 diff ec271e139f35091cee6d14d3af846e515b7594f0 동일/새 파일0도 확인했습니다. 가상 자원·서버·민감 파일은 모두 정리하고 포트를 반환했습니다. 로컬 HTTP 통과를 브라우저·배포 성공으로 표현하지 않습니다.

기준 dev ed0dbea5ae250b9b234d54dee9a432d5ba58098f, head test/alt-311. 검증 환경은 V15 schema-only+matching Flyway history와 합성 데이터이며 fresh V1 전체 적용 결과가 아닙니다. 최종 통합은 승인된 V15 snapshot/history→V16/새 migration·build/API 기준으로 확인합니다. 이번 새 migration 0.

ALT298/301/305와 함께 최종 회귀가 필요합니다. dev 기준에는 ALT301 직렬화 패치가 없으므로 순차 충돌 경로를 동시성 해결로 판정하지 않습니다. PR105 예상 수입 개선은 범위 밖이며 가져오지 않았습니다. 실제 화면/딥링크·배포·외부 OAuth/메일/S3/기기 FCM·cron은 별도 QA입니다. 병합/배포는 사람이 수행합니다.

Notion: https://app.notion.com/p/3ef8655316288128924eec9e97b0e543

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: alter-app/alter-backend
• Branch: test/alt-311
• File: .coderabbit.yaml
• Commit: 3ef54c0
• Layers: Repository YAML
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: f343507b-578e-498c-8ce6-fc957eca2ef0

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[hodoon]

리뷰했습니다. 인라인 코멘트 확인 부탁드립니다.

[hodoon]

anchor 이름을 구하는 subquery가 cursorWorker.workspace.eq(qWorkspaceWorker.workspace)로 바깥 행을 참조하고 있어서 상관 subquery가 되는 것 같습니다.
세 호출 경로 모두 WHERE에 qWorkspace.id.eq(workspaceId)가 이미 있어서 결과는 같습니다. 그런데 이 subquery가 gt/eq 양쪽에 들어가 있어서, Postgres가 행마다 SubPlan을 두 번씩 평가할 수 있습니다.
cursorConditions에 workspaceId를 넘겨 cursorWorker.workspace.id.eq(workspaceId)로 비교하면 어떨까요? 비상관 subquery가 되어 한 번만 평가되고, 업장 격리도 그대로 유지될 것 같습니다.