파싱 알림의 라우팅·문구를 수신자별로 해석 (+ wishId 딥링크)

[sevineleven]

상위 Epic

없음

왜

파싱 알림의 라우팅과 문구가 이벤트 단위로 한 번 해석돼 전 수신자에게 그대로 복사된다. NotificationDispatcher.dispatch 가 resolveRouting(event) 과 title/body 렌더를 수신자 루프 밖에서 부르기 때문이다.

한 snapshot 에 서로 다른 출처의 수신자가 함께 붙을 수 있어서 이게 문제가 된다. 공유 정체성(#825)의 "진행 중 합류" 경로다.

1. A 가 URL 을 위시에 등록 → wish(A, snapshot S = PENDING)
2. 파싱이 도는 중에 B 가 같은 URL 을 토너먼트에 등록
3. TournamentItemPersistenceService → ItemSharingService.resolveAttachment → attachOrNull 의 findLatestInProgressByItemId 가 같은 S 를 물려준다 → tournament_item(B, S)
4. 파싱 완료 → 수신자 {A, B}, 라우팅은 firstOrNull 로 고른 토너먼트 하나

결과: 위시에만 담은 A 가 B 의 토너먼트로 가는 딥링크를 받는다. ItemParsingRecipientResolver.resolveRouting 주석이 이 선택을 "결정성만 있으면 된다" 로 적어 두었지만, 결정적인 것과 수신자에게 맞는 것은 다르다.

같은 구조 때문에 두 가지가 막혀 있다.

• 출처별 문구 — 파싱 완료 알림을 제목=아이템 이름 / 본문=상태 문구 구조로 분리 #913 에서 위시/토너먼트 문구를 가르려다, 위시 수신자가 토너먼트 문구를 받는 문제가 드러나 단일 문구로 되돌렸다 (파싱 완료 알림을 제목=아이템 이름 / 본문=상태 문구로 분리 #924, CodeRabbit 지적).
• wishId 딥링크 — 클라가 요청한 필드. 위시 상세는 GET /api/v1/wishlists/{wishId} 라 현재 payload 의 refId(itemId)로는 갈 수 없어 목록에서 역추적하고 있다. wishId 는 수신자마다 다르므로 이벤트 단위 라우팅에 실으면 남의 위시 id 가 박힌다. 없는 것보다 나쁘다(403/404).

무엇을

파싱 알림의 라우팅과 문구를 수신자별로 해석한다. 그 위에 위 두 가지를 얹는다.

1. 수신자별 라우팅

• 위시 주인 → Wish, 토너먼트 등록자 → 자기 Tournament(tournamentId, tournamentItemId)
• 한 유저가 양쪽에 다 있으면 어느 쪽을 쓸지 규칙을 정해 못 박는다
• 조회는 배치 1회로 — 수신자 수만큼 쿼리가 늘지 않게 한다. ItemParsingRecipientResolver.resolve 가 이미 wish·tournament_item 을 읽고 있어 그 쿼리가 식별자를 함께 반환하면 된다

2. 수신자별 문구

• 템플릿 렌더를 수신자 루프 안으로 옮기고, 라우팅에서 파생한 변수를 함께 넘긴다
• 출처별 완료 문구 복원: 위시 "위시 저장이 성공했어요" / 토너먼트 "아이템이 등록됐어요"
• 실패 알림은 이름이 없어(FAILED snapshot 의 name 이 빔) 현행 단일 문구 유지
• 문장을 통째로 변수에 담으면 백오피스(notification_templates 테이블 및 알림 내용 DB 관리 구현 #252) 편집을 잃는다. 템플릿 테이블이 타입당 한 행(PK=type)이라 body 를 두 벌 둘 자리가 없어서인데, 이 제약을 어떻게 풀지도 함께 정한다

3. wishId payload 필드

• notifications 에 wish_id 컬럼 (FK 없음)
• NotificationRouting.Wish 를 object → 식별자를 든 형태로
• SSE payload WishParsing 셰입과 FCM data 양쪽에 노출
• 과거 행은 wishes ⋈ item_snapshots 를 (user_id, ref_id) 로 이어 backfill 가능. 안 해도 보존기간 30일이면 빠진다
• refId 의미는 그대로 둔다 (클라 요청도 그렇다)

검증

• 같은 snapshot 을 위시 주인과 토너먼트 등록자가 공유하는 dispatch 통합 테스트에서 수신자별 body·routing·wishId 를 각각 단언한다
• 이 테스트는 현재 구조에서 반드시 실패해야 한다 (negative control)

참고

• 되돌린 커밋과 판단 근거: 파싱 완료 알림을 제목=아이템 이름 / 본문=상태 문구로 분리 #924
• 클라 요청 원문: 파싱 알림 payload 에 wishId 추가 (SSE·푸시 양쪽)