fix(core): 수신자 목록 캐시의 로그인 세션 경계 보장 (#2135)

[1hyok]

먼저 볼 파일: TokenDataSource.kt의 로그인 세션 식별자, UserReceiverRepositoryImpl.kt의 목록 캐시 수명, ReceiverSessionBoundaryRaceTest.kt의 실제 DataStore 회귀입니다.

📌𝘐𝘴𝘴𝘶𝘦𝘴

• Closes fix(core): 새 로그인 세션에서 이전 수신자 캐시를 폐기한다 #2135
• Refs fix(core): 수신자 목록의 로딩·실패 결과를 보존한다 (#1281 분리) #2045

📎𝘞𝘰𝘳𝘬 𝘋𝘦𝘴𝘤𝘳𝘪𝘱𝘵𝘪𝘰𝘯

로그아웃과 새 로그인 사이의 Boolean 방출을 수집자가 놓치면 기존 목록 Flow가 유지돼, 새 세션의 조회 실패에 이전 세션 캐시가 다시 나오는 문제를 고칩니다. 로그인 토큰과 함께 새 세션 식별자를 저장하고, 토큰 회전과 기존 저장 토큰에서는 식별자를 유지합니다.

실제 세션 교체에는 빈 목록을 먼저 내보냅니다. 조회 결과를 처리하기 전에 저장된 식별자를 재확인해, 다른 세션의 결과로 확인되면 성공 응답과 실패 캐시를 모두 반영하지 않습니다. 최초 구독의 서버 조회, 같은 세션의 일시 실패 캐시, 401 처리와 취소 전파는 유지합니다.

실제 base는 develop입니다. 선행 #2120과 #2130이 병합된 64935936ef8f981764922104ce8879ebff52cb0b를 통합했습니다. 목록 DTO와 수정 후 갱신을 유지하며, 최신 develop의 좁은 UserRepositoryImpl 생성자에 실제 세션 저장소 fixture를 연결했습니다. 계정·푸시 기능의 이전 합본 API는 복원하지 않습니다.

🧪 검증

• 실제 Preferences DataStore와 공개 인증·수신자 저장소 계약으로 기존 캐시 재사용을 재현했습니다. 세션 교체 직후 빈 목록과 관측 전 늦은 응답 회귀도 수정 전 실패, 수정 후 통과했습니다.
• 최신 develop 통합 후 core:data 단위 테스트 82개와 core:datastore 11개 통과. 실패·건너뜀 0개이며, 두 모듈 ktlintCheck와 app의 main·unit test·androidTest Kotlin 컴파일도 통과했습니다.
• 토큰 회전·기존 토큰 호환, 세션 교체의 빈 목록, 늦은 성공·실패 보호를 제거한 변형들이 해당 회귀에서 실패하는 것을 확인했습니다.

🧪 CI Test Plan

{
  "androidTest": {
    "mode": "selected",
    "reason": "수신자 저장소의 세션 경계 변경으로 실제 DataStore 회귀를 단위 테스트에서 검증하고, 기존 화면이 빈 목록 전환을 소비하는 계약을 API 30과 34에서 확인합니다.",
    "tests": [
      {
        "path": "app/src/androidTest/java/com/afternote/afternote_fe/ReceiverSessionIsolationAndroidTest.kt",
        "selector": "com.afternote.afternote_fe.ReceiverSessionIsolationAndroidTest#recipientList_receiverListEmptiesOnSessionChange_keepsScreenAliveWithoutPreviousReceiverIdentity",
        "device": "api30"
      },
      {
        "path": "app/src/androidTest/java/com/afternote/afternote_fe/ReceiverSessionIsolationAndroidTest.kt",
        "selector": "com.afternote.afternote_fe.ReceiverSessionIsolationAndroidTest#recipientList_receiverListEmptiesOnSessionChange_keepsScreenAliveWithoutPreviousReceiverIdentity",
        "device": "api34"
      }
    ]
  }
}

💬𝘛𝘰 𝘙𝘦𝘷𝘪𝘦𝘸𝘦𝘳𝘴

현재 화면에서 다른 계정 목록이 노출되는 경로까지 재현한 결과는 아닙니다. 화면은 로그아웃 때 백스택과 ViewModel을 정리하며, 이 변경은 장수하는 저장소 구독의 기존 세션 격리 계약을 바로잡습니다. 세션 재확인과 방출 전체가 원자적이라는 보장은 추가하지 않습니다.

선택 계측 테스트는 기존 화면 소비 계약의 호환성을 확인합니다. 실제 DataStore의 경합 재현 근거는 위 단위 테스트입니다.

[github-actions]

열린 PR 중 이 PR 과 같은 파일을 서로 다르게 고친 것이 있다. 어느 쪽이 먼저 머지되든 나중 쪽은 base 를 병합해야 통과한다 (#1750).

• fix(timeletter): 서버 실패 상태와 재시도 처리 (#714) #1365 — core/data/src/main/java/com/afternote/core/data/repoimpl/UserReceiverRepositoryImpl.kt

머지 자체는 GitHub 이 막는다 — 한쪽이 들어가면 다른 쪽은 CONFLICTING 이 되어 merge queue 에 못 들어간다.
이 라벨은 그 전에 순서를 정하라는 신호다. 먼저 갈 쪽을 정하고, 나중 쪽은 그 머지 뒤에 base 를 병합한다.
상대 PR 에도 같은 안내가 달린다.

이 코멘트는 리컨사일러가 매 실행 현재 상태로 고쳐 쓴다. 해소되면 sibling-conflict 라벨은 자동으로 떨어진다.

[github-actions]

이 PR 은 develop 와 충돌 상태이고, 그래서 CI 가 돌지 않는다.

pull_request 워크플로는 base 와 head 를 합친 가상 머지 커밋(refs/pull/<N>/merge)에서
실행되는데, 충돌이면 GitHub 이 그 ref 를 만들지 못해 워크플로가 트리거조차 되지 않는다.
체크가 실패하는 것이 아니라 아예 생성되지 않으므로, 새 커밋을 올려도 no checks reported
인 채 최신 커밋이 한 번도 검증되지 않은 상태로 남는다 (#1028).

develop 를 병합해 충돌을 풀면 검증이 다시 돈다. 해소되면 이 라벨은 자동으로 떨어진다.