Repository navigation
fix(afternote): 에디터 수신자 목록을 UserRepository 로 연결 — 죽은 AuthorReceiverRepository 제거 (closes 935) [base: develop] - #971
Conversation
…pository 제거 AuthorReceiverRepositoryImpl 은 currentAuthorUserId() 가 항상 null 이라 refreshReceivers() 가 늘 실패하고 observeReceivers()·currentReceivers() 는 빈 리스트만 반환하는 죽은 구현이었다. 에디터가 이를 프로덕션 경로에서 소비해 신규 작성 시 수신자 목록이 항상 비었고, 수신자 최소 1명이 서버 필수값(475)이라 등록 자체가 막혔다. 같은 기능을 하는 core:domain 의 UserRepository 로 전환한다. GET users/receivers 는 파라미터가 없고 서버가 액세스 토큰으로 호출자를 식별하므로 userId 개념 자체가 불필요하다 — 코드베이스 어디에도 저장되지 않던 값이다. - AfternoteEditorViewModel: 죽은 flow 구독을 걷고 refreshAuthorReceivers() 가 userRepository.getReceivers() 로 목록을 채운다. 조회 실패는 삼키지 않고 AUTHOR_RECEIVER_LOAD 단계로 계측하며, runCatchingCancellable 로 취소는 보존한다 - AuthorReceiverEntry 를 core:model 의 Receiver 로 통합하고 매퍼를 EditorReceiverMapping 으로 옮긴다 (수신 타입도 호출처에 맞춰 List 로 좁힘) - AuthorReceiverRepository·Impl·Entry 와 DI 바인딩 삭제, androidTest 전용 Fake 3종은 공용 FakeUserRepository 로 교체 수신자 선택 화면 라우팅(#540)은 #791 선행이 남아 별건이다.
실서버 QA 완료 — 미검증으로 남겨 뒀던 항목 해소 (2026-08-24 13:22~13:32 KST)PR 본문에 "서버 복구 후로 남는다" 고 적어 둔 응답 데이터 검증을 마쳤다. 커밋 1. 수신자 목록이 실제로 폼에 채워진다
{"status":200,"code":200,"message":"성공","data":[{"receiverId":14,"name":"QA수신자","relation":"DAUGHTER","authCode":"683fec31-..."}]}노트 탭 → FAB → 소셜네트워크 에디터 진입 시 "수신자 추가" 섹션에 2. 저장까지 완주 — 475 데드엔드가 실제로 풀린다서비스명(인스타그램)·계정정보·처리방법을 채우고 등록: POST /api/v1/afternotes
{"category":"SOCIAL","title":"인스타그램","actions":["delete account"],
"credentials":{"id":"qa935_dummy_id","password":"qa935_dummy_pw"},
"receivers":[{"receiverId":14}]}
<-- 200
부수 확인 — 화면의
|
#1005(추모 미디어 업로드 경로 통합)가 먼저 develop 에 들어가 사진 전용 MemorialPhotoUpload* 가 MemorialMediaUpload* 로 바뀌었고, 이 브랜치는 AuthorReceiverRepository 를 지우고 UserRepository 로 갈아끼우는 쪽이라 DI 모듈 import 가 양쪽에서 갈렸다. 남는 쪽(MediaUpload)만 두고 지워진 쪽(PhotoUpload·AuthorReceiver) 은 모두 뺀다. androidTest editorViewModel() 헬퍼는 develop 의 itemId(Long) 형태를 취한다 — #949 가 String→Long 드리프트를 고친 결과이고 같은 파일의 다른 호출부도 Long 이다. 수신자 주입만 이 브랜치의 FakeUserRepository 로 남긴다. :app:compileDebugUnitTestKotlin 통과. androidTest 오류 21건은 develop 에서 그대로 물려받은 것으로 오류 집합이 develop 과 동일하다.
Closes #935
AuthorReceiverRepositoryImpl은currentAuthorUserId()가 항상null이라refreshReceivers()가 늘 실패하고observeReceivers()·currentReceivers()는 빈 리스트만 반환하는 죽은 구현이었다. 에디터가 이를 프로덕션 경로에서 소비해 신규 작성 시 수신자 목록이 항상 비었고, 수신자 최소 1명이 서버 필수값(475)이라 등록 자체가 막혔다.같은 기능을 하는
core:domain의UserRepository로 전환한다. 수신자 목록 소비처 7곳이 이미 이것을 쓰고 있었다.변경
AfternoteEditorViewModelrefreshAuthorReceivers()가userRepository.getReceivers()로 목록을 채운다EditorReceiverMapping(rename)AuthorReceiverEntry→core:model의Receiver기준으로 재작성, 수신 타입도 호출처에 맞춰List로 좁힘AfternoteFailureReportingAUTHOR_RECEIVER_LOAD계측 단계 신설AuthorReceiverRepository·Impl·AuthorReceiverEntry, DI 바인딩bindAuthorReceiverRepositoryFakeUserRepository조회 실패는 삼키지 않고 계측하며,
runCatchingCancellable로 취소는 보존한다.userId를 폐기한 근거GET users/receivers는 파라미터가 없고 서버가 액세스 토큰으로 호출자를 식별한다. 실제로 userId 는 코드베이스 어디에도 저장되지 않는다 — main 소스 전체에서userId는 8곳뿐이고 전부 회원가입 응답 경로(AuthDto→AccountRegistration→AuthMapper)와 이 죽은 Impl 이다. TODO 가 안 풀린 건 채울 소스가 없어서가 아니라 채울 필요가 없어서였다.검증
:feature:afternote:{presentation,data}:compileDebugKotlin:app:compileDebugKotlin·:app:compileDebugUnitTestKotlin:app:assembleDebugktlintCheck:app:testDebugUnitTest+ afternote presentation·data:app:compileDebugAndroidTestKotlinorigin/develop기준선과 오류 집계가 완전히 동일(파일별 수치까지 일치). 이 브랜치가 추가한 오류 0건이며, 기존 드리프트는 #949 가 처리 중에뮬레이터 실측 (2026-08-24 02:43~02:45 KST,
Pixel_7_Claude_QA)노트 탭 → FAB → 소셜네트워크 에디터 진입 시:
Authorization헤더만 실린다 — userId 불필요가 런타임에서 확인됨receiverListFlow크래시 회피 포함)미확인: 응답 목록이
replaceReceiversIfEmpty로 폼에 실제로 채워지는지. dev 서버가 02:45 시점에 이미 무응답이라(메모리상 폐쇄 시간대 03~12시보다 이르게 닫힘) 응답 데이터 검증은 서버 복구 후로 남는다.시각 검증
시각 변경 없음 — 변경 파일이 ViewModel·매퍼·DI·내비게이션 로직뿐이고 Compose 본문·디자인 토큰·리소스·screenshotTest 커버 대상은 건드리지 않는다. baseline 사이클 skip.
리뷰어에게
EditorFormPrefill주석이 명시한 원래 과도기 설계) 불필요한 수신자는 기존 삭제 버튼으로 뺀다. 그 결과 475 데드엔드는 풀리지만, "골라서 추가" 진입점은 여전히 무동작이다 — 수신자 선택 화면 라우팅은 에디터 수신자 지정 불가 — 선택 화면 라우팅 미연결 + AuthorReceiverRepository 죽은 구현 (전 카테고리 신규 등록 차단) #540 이고 공용 컴포넌트 추출 수신자 선택 화면을 공용 컴포넌트로 추출 #791(koongmai) 이 선행이라 별건이다AfternoteEditorReceiver.id가String이라 저장 직전mapNotNull { it.id.toLongOrNull() }로 되돌리는 구조는 그대로 뒀다. 현재 두 생성 경로 모두receiverId.toString()이라 실제 누락은 없지만 실패를 삼키는 자리라, 폼 모델 타입 정리로 refactor(afternote): 에디터 수신자 폼 모델 id 를 Long 으로 좁힌다 — String 왕복·mapNotNull 무증상 누락 제거 #970 을 따로 열었다