Repository navigation
FCM 목적지 payload 확정 계약과 현재 HOME 동작을 대조한다 #1988
Description
작업 유형
enhancement — 신규 기능·기존 기능 개선
주 담당 모듈
app — 앱 셸·루트 네비게이션·앱 모듈 공통
개요
AfternoteFirebaseMessagingService 는 #1641 에서 알림 목적지 계약값(NotificationDestination)이 생긴 뒤에도 FCM 푸시를 전부 HOME 으로 고정해 띄운다. 서버가 payload 형태(notification vs data-only)와 목적지 data 키를 아직 확정하지 않아(Afternote/Afternote-BE#261) 키를 추측하면 서버가 다른 이름을 고르는 순간 fromContractValue 가 null 을 돌려주는 분기가 조용히 죽기 때문이다. 그 자리에 «계약이 확정되면 여기서 data 를 읽어 옮긴다» 는 주석만 남아 있고 후속 FE 이슈가 없다.
현재 범위: 계약 확인
- BE#261의 확정 payload 형태와 목적지 data 키의 존재 여부를 확인한다.
- 현재 HOME 동작·NotificationDestination 계약과 대조해 실제 변경 필요 여부를 기록한다.
- 목적지가 없는 계약이면 기존 HOME 동작을 유지한다. 목적지 전달 계약이 확정되면 그때 필요한 변경·폴백 정책·검증을 정한다.
- 미확정 키, HOME 폴백, 로그 방식, 테스트 3분기를 구현 계획으로 미리 고정하지 않는다.
완료 조건: 확정 payload 근거와 현재 구현의 차이가 기록된다. data 목적지가 없는 경우에도 변경 불필요로 완료할 수 있다.
참고
- 선행: [feat] FCM 푸시 발송 계약 확정 — payload 형태(notification vs data-only)와 목적지 data 키 Afternote-BE#261 (blocked_by 로 연결)
- 계약값 enum 과 Intent 배선은 fix(app,core): 알림 목적지를 계약값으로 실어 진입 큐까지 전달한다 (#1727) #1641 (머지됨), 원 이슈 알림 탭이 목적지로 갈 수 없는 구조 — MainActivity onNewIntent 부재, PendingIntent 빌더 2벌 중복 #1111
Activity
[-]FCM 푸시의 목적지를 payload 계약값으로 읽어 NotificationDestination 으로 옮긴다[/-][+]FCM 목적지 payload 확정 계약과 현재 HOME 동작을 대조한다[/+]OnlyReadOneBook commentedon Sep 13, 2026
Afternote-BE#261 에 코멘트로 오래 답이 없어 축을 좁혀 다시 물었다(2026-09-13).
물은 내용은 묵은 본문을 옮긴 것이 아니라 Afternote-BE main 실코드로 대조해 다시 벼린 것이다. 코드로 이미 답이 나온 축은 질문에서 빼고 사실로 적었다.
OnlyReadOneBook commentedon Sep 13, 2026
확정 payload 근거와 현재 구현의 차이 (2026-09-13 실측)
기준 리비전은 FE
origin/develop7d87aa3f4, BEmain3593aa30c다. BE 는 2026-09-09 이후 push 가 없고 열린 PR 도 0건이다.1. BE#261 은 아직 확정 전이다
main의 FCM 코드는 이슈 개설(2026-08-29) 이후 한 줄도 바뀌지 않았다.src/main/java/com/afternote/domain/notification을 마지막으로 만진 커밋이fbd2a5d82(2026-08-17) 다.FcmPushSender.sendOne은 여전히setNotification(...)을 무조건 세팅하고(FcmPushSender.java:59-64)data는 비어 있지 않을 때만putAllData한다(:66-68). 목적지를 뜻하는 키는 없다.FcmPushSender를 부르는 프로덕션 코드는AdminPushTestService하나이고 실어 보내는 data 는Map.of("type", "TEST")뿐이다(AdminPushTestService.java:43). 실서비스 발송 트리거는 아직 없다.domain/delivery/service/DeliveryNotificationService는JavaMailSender로 이메일만 보낸다. FCM 을 부르지 않는다.확정 payload 근거로 삼을 서버 구현이 없다. 그래서 지금 기록할 수 있는 것은 미확정이라는 사실과 아래 대조표다.
2. 대조표
notification항상,data는 선택notification.title/body를 먼저 보고 없으면data["title"]·data["body"]로 그린다 (AfternoteFirebaseMessagingService.kt:145-146,:157-158)data에서 목적지를 읽지 않는다.NotificationDestination.HOME으로 고정해 PendingIntent 를 만든다 (AfternoteFirebaseMessagingService.kt:98-108)fromContractValue가 기대하는 입력com.afternote.notification.DESTINATION의 문자열 하나다. FE 가 쓰고(NotificationPendingIntentFactory.kt:39,:55) FE 가 되읽는다(NotificationIntentContract.kt:58,:87)data는 이 함수에 도달한 적이 없다. 지금은 FE 가 스스로 쓴 값을 되읽을 뿐이다home,mind_record,time_letter,afternote넷이다 (NotificationDestination.kt:17-20). 대소문자를 구분하고 앞뒤 공백만 다듬는다 (:30-34,NotificationDestinationTest.kt:20,:26-31)HOME은 계약 밖 값이다NotificationIntentContract.kt:87-88,:93, 테스트NotificationIntentContractTest.kt:113-123)MainActivity가 큐에 넣고(MainActivity.kt:43,:87-97)MainViewModel이 들고만 있다(MainViewModel.kt:25-29). 프로덕션 소비처는 0건이다AfternoteFirebaseMessagingService.kt:62, 테스트AfternoteFirebaseMessagingServiceTest.kt:60-65)3. 차이의 실체
FE 는 세 조각으로 나뉘어 있다.
data에서 title/body 만 읽고 목적지는 HOME 으로 고정한다. 왜 추측하지 않는지는AfternoteFirebaseMessagingService.kt:98-101주석에 남아 있다.NotificationPendingIntentFactory.kt:30-39).NotificationEntryEffect.kt를 걷어냈고(ea7d65d13, 2026-09-04) 라우트 매핑 파일도 지웠다(f282cfc91, 2026-09-08). 그 범위는 feat(platform): 알림 목적지 이동을 앱 루트에 결선한다 — #1727 에서 Nav3 재작성분 분리 #1795 가 들고 있다.BE 가 목적지 키를 확정하면 FE 가 고칠 곳은 1번 한 곳이다. 그 값이 실제 화면 이동까지 이어지려면 3번(#1795)이 먼저거나 같이 가야 한다.
4. BE#261 에 적힌 FE 제약 두 가지는 지금 코드와 다르다
NotificationPendingIntentFactory.create(payload = null)은 실제 시그니처가 아니다. 이 함수에payload인자는 develop 어느 리비전에도 없었다. 처음 들어온af909a635(2026-08-28, 알림 PendingIntent 진입 인프라를 통합하고 warm 재진입을 보존한다 #1310)의 시그니처는(context, source, occurrenceToken)이고 지금은(context, source, occurrenceId, destination)이다(NotificationPendingIntentFactory.kt:41-46). payload 라는 낱말은 코드 주석에만 있었고01cc2637c에서 지워졌다.그래서 서버가 정해 줄 것은 둘로 줄어든다. payload 형태(data-only 냐 notification 유지냐)와 목적지 키 이름 하나다. 값은 위 네 계약값이면 되고, 파라미터 타입 규약은 물을 필요가 없다.
5. 이 이슈의 상태
완료 조건은 "확정 payload 근거와 현재 구현의 차이가 기록된다" 인데 앞쪽 절반을 아직 채울 수 없다. 서버에 확정 payload 도, 결정도 없다. 이 코멘트는 현재 구현 쪽을 실측으로 고정해 둔 것이고, BE#261 이 답하면 대조표의 두 줄(목적지 data 키, 허용 값 집합)만 채우면 판정이 끝난다. 그때 data 목적지가 없는 계약으로 결론이 나면 변경 불필요로 닫는다. 선행 관계는 BE#261 로 이미 blocked_by 가 걸려 있다.
OnlyReadOneBook commentedon Sep 26, 2026
보류로 닫는다. 완료 조건의 앞쪽인 확정 payload 근거를 쓸 수 없다.
Afternote/Afternote-BE#261 의 결정 셋(payload 형태, 목적지 data 키, 문구 소유자)이 모두 미체크이고 담당자 답이 없다. BE
origin/main7c961ec 의FcmPushSender는 2026-08-17 이후 바뀌지 않았고, 지금도 notification 을 항상 싣는다. 목적지를 배선할지 접을지부터 BE 선택에 달려 있어서 무엇을 만들지가 정해지지 않은 상태다(공유 정책의 결정 뒤 등록 기준).09-13 댓글의 대조 내용은 닫아도 남는다. BE#261 이 정해지면 그 결정으로 새 이슈를 연다. data-only 로 키가 정해지면 목적지 읽기 구현이고, notification 유지로 정해지면 목적지 배선을 접는 기록이다.