fix(setting): 오류 상태 처리를 안정화한다 (#708)

[OnlyReadOneBook]

작업 내용

• 설정 홈, 프로필 수정, 연결 계정, 푸시 알림에서 초기 조회 실패를 로딩·오류 상태와 재시도로 표시합니다.

• 중복 로드를 막는 job 가드와 runCatchingCancellable을 적용하고 계정 연결·해제 실패를 UiState 신호로 전달하고 ConsumeEvent Intent로 소비합니다.

• 분리된 ConnectedAccountsContent·PushNotificationContent에 오류 화면 분기를 연결하고 ViewModel 회귀 테스트와 푸시 알림 스크린샷을 포함합니다. 수신자 목록은 develop의 공용 선택 화면 구조를 따릅니다.

• #1967의 6개 설정 ViewModel MVI 계약을 실제 부모로 사용합니다. 오류 처리에서 새 Channel이나 별도 public 입력 함수를 도입하지 않습니다.

• 이 PR이 함께 수정하는 SettingViewModel도 MVI로 전환해 프로필·로그아웃·탈퇴 상태를 하나의 UiState에 모았습니다. #1805가 같은 소비처를 다시 작성할 범위를 제거합니다.

연결 이슈

• Closes 서버 조회 실패가 로그아웃·빈 목록·OFF 기본값으로 위장 — 오류·재시도 상태 미결선 #708

설정 담당 이관

원본 PR #1709의 설정 작업을 1hyok 명의로 이어받습니다. 인수 기준 커밋은 be17a0327a670e57f46a3a4f3b63ebbc3c7b8e12이며 기존 커밋의 작성 이력은 보존합니다. 원본의 승인·변경 요청은 새 PR로 자동 이전되지 않으므로 다시 리뷰받습니다.

기존 리뷰 반영

• 푸시·연결 계정 조회 오류를 UiText.Resource로 전달하고 화면이 그 값을 표시합니다. 설정 홈의 프로필 오류는 SettingProfileState.Error 에서 message 를 없애고 화면이 setting_profile_load_error 리소스를 그립니다. 같은 문장이 코드와 리소스 두 곳에 있던 것을 리소스 하나로 모았습니다. 사용되지 않는 setting_receivers_load_error는 제거했습니다.
• develop에 반영된 #1924의 서비스 알림 저장 실패 안내 위에 조회 오류·재시도를 통합합니다. 마케팅 동의 및 저장 실패·재시도 동작을 보존했습니다.
• 마케팅 동의/기기 알림 설정을 하위 서비스 알림 화면에 다시 중복 표시하던 병합 충돌을 해소했습니다. 정상 상태의 토글 세 개는 Column으로 세로 배치합니다.

원본 변경 요청을 반영했습니다.

검증

• MVI 적응 후 설정 전체 단위 테스트 80개 및 Konsist 56개 통과(실패 0), 양쪽 ktlintCheck, Debug screenshotTest Kotlin, 앱 main/unit/androidTest Kotlin 컴파일 성공. 로그아웃 신호 보존·소비·재전달, 중복 탈퇴 및 늦은 오류 닫기 회귀를 추가했습니다.

• 실제 base: refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 (refactor/1502-setting-state-mvi). refactor(setting): 설정 로컬 Navigation 3 스택 이관 (#1695) #1962 → refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502) #1967 → fix(setting): 오류 상태 처리를 안정화한다 (#708) #1925 → fix(setting): 설정 하위 화면 4종의 재진입 갱신 (#1920) #1930 순서이며 fix(setting): 마케팅 알림 수신 동의(문자/이메일/푸시)가 저장되지 않던 문제 수정 (#560) #1923/#1924는 develop에 이미 반영되어 있습니다.

• 최신 공통 UI를 통합한 HEAD에서 CI 표준 amd64 생성 실행과 적용 실행이 성공했습니다. bot 커밋 597bc755b는 기준 PNG 5개만 변경합니다. 연결 계정 로딩과 푸시 정상·compact·오류·로딩 화면의 한글, 세 토글 배치, 하단 안내를 직접 확인했습니다.

CI Test Plan

{
  "androidTest": {
    "mode": "full",
    "reason": "설정 메인·탈퇴의 aggregate UiState 소비를 SettingNavHost에 연결하므로 전체 계측 lane을 실행한다. 조회 오류·재시도 및 상태 소비는 Robolectric 회귀와 SettingImplementedCoverageAndroidTest의 실제 설정 host 경로로 검증한다. 앱 main/unit/androidTest Kotlin 컴파일을 확인했다.",
    "tests": []
  }
}

확정된 설정 계약 통합

#1967에서 #1691·#1739·#1429를 함께 구현한 최종 계약을 실제 부모로 통합했습니다. 이 PR의 소비자와 회귀 fixture는 좁은 프로필·수신자 계약 및 설정 소유 계정·알림 계약을 직접 사용하며, 저장 정책은 두 UseCase를 사용합니다. 별도 후속 저장소·UseCase 재작성은 예약하지 않습니다.

최신 통합 검증: 설정 presentation 82개 테스트 통과(실패·오류 0), 앱 main/unit/androidTest Kotlin 컴파일 및 setting ktlint 통과. #1962의 실제 Nav3 SavedState serializer 회귀도 포함합니다. 화면 배치는 변경하지 않았습니다.

공용 텍스트 타입 제거 반영

독립 PR #2006 (#1887)의 미사용 UiText.DynamicOrResource 제거를 반영하고, 연결 계정의 문자열 변환에서 해당 타입 분기를 함께 삭제했습니다. 기존 Resource·Dynamic 표시는 유지됩니다. 실제 base와 기존 설정 기능 범위는 유지합니다.

검증: 현재 HEAD에서 설정 오류 회귀 9개, 앱 debug Kotlin 컴파일, 설정·코어 ktlint 통과.

[github-actions]

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

• refactor(setting): 수신자 목록을 MVI와 lifecycle Intent로 전환 (#1805) #2018 — konsist/src/test/kotlin/com/afternote/konsist/MviContractKonsistTest.kt

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

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

[github-actions]

📸 CI 표준 환경에서 screenshot baseline 5개를 생성·검증해 597bc75 로 커밋했습니다.
실행 로그·생성 artifact: https://github.com/Afternote/Afternote-FE/actions/runs/34188744646
이미지 내용은 이 PR의 PNG diff에서 눈으로 최종 확인해 주세요. 필수 검사도 새 SHA에 다시 요청했습니다.

[OnlyReadOneBook]

변경 요청 3라운드 6건을 현재 head 7dfcb431a 에서 다시 확인했습니다. 지난 답변의 b9de721 뒤로 base 병합이 네 번 들어왔고 그중 하나가 UiText 표시 경로를 손대서, 병합이 되돌린 것이 없는지 줄 단위로 대조했습니다. 여섯 건 모두 남아 있어 새로 고칠 코드는 없습니다.

1라운드

• 갱신 중 Loading 되돌림. SettingViewModel.kt:45 의 ProfileLoading 이 if (state.profile is SettingProfileState.Success) state else state.copy(profile = SettingProfileState.Loading) 이라, RESUMED 마다 부르는 refresh() 는 기존 Success 를 유지하고 최초 로드와 오류 재시도에서만 스피너가 섭니다.
• 오류 화면의 로그아웃. SettingScreen.kt:260-272 의 SettingProfileState.Error 분기가 재시도 본문 아래에 settings_logout 항목과 기존 확인 다이얼로그를 함께 둡니다.
• 새 로딩 두 곳. ConnectedAccountsContent.kt:59 와 PushNotificationContent.kt:62 가 LoadingBody() 입니다. SettingScreen·ProfileEditScreen·ReceiverEditContent 에 남은 raw CircularProgressIndicator 는 이 PR 이 쓴 줄이 아니라 refactor(timeletter,setting): 로딩 스피너 6곳을 core:ui LoadingBody 로 치환 (#641 분리) #1491 범위로 둡니다.

2라운드

• SettingProfileState.Error 는 SettingContract.kt:22 에서 message 없는 data object 이고, 화면 두 곳(SettingScreen.kt:263, ProfileEditScreen.kt:123)이 stringResource(R.string.setting_profile_load_error) 를 그립니다.

3라운드

• 연결·해제 실패 문구. ConnectedAccountsViewModel.kt:106,112 가 setting_connected_accounts_link_error 와 setting_connected_accounts_unlink_error 를 mutate() 에 넘기고 실패는 UiText.Resource(errorResId) 로 나갑니다. 설정 presentation 의 main viewmodel 디렉터리에서 한글 문자열 리터럴은 0건입니다.
• provider 별 진행 판정. mutationJobs 가 provider 키 맵이라(ConnectedAccountsViewModel.kt:27, 조기 반환은 :122) 같은 provider 연타만 막고 다른 계정 토글은 그대로 받습니다. 회귀는 SettingErrorStateViewModelTest 의 "연결 계정은 한 provider 요청 중에도 다른 provider 조작을 무시하지 않는다" 와 "연결 계정은 같은 provider 요청이 진행 중이면 연타를 한 번만 보낸다" 두 건입니다.

커밋은 전부 origin 에 올라가 있고 이 head 에서 Unit Test, Ktlint, Android Lint, screenshot, Pixel 2 API 30 androidTest 가 통과입니다. 남은 red 는 guard 하나인데 #708 이 아직 열린 #1502 에 blocked 이고 base 가 refactor/1502-setting-state-mvi 라서 나는 스택 순서 판정이라, 선행이 develop 에 들어가면 풀립니다.

[github-actions]

스택 연결 조치 필요

#1967 이 머지되지 않은 채 닫힌 시점에 네이티브 스택 #1970 에 남아 이 PR의 스택 병합을 막는 것으로 감지됐습니다.

머지 전에 기존 스택을 해제하고, 필요한 열린 PR만 의도한 순서로 다시 연결해 주세요.

gh stack unstack 1970
gh stack link --base develop <아래 PR> <위 PR>

unstack/relink 자체에는 Actions 이벤트가 없어 이 기록이 남을 수 있습니다. 현재 병합 가능 여부는 merge queue의 live 검사를 기준으로 확인하세요.

[OnlyReadOneBook]

PM 결정을 기다리는 항목은 깃허브에 열어 두지 않고 피그마 질문 한 자리에만 둔다(2026-09-18 일혁 결정). 이 PR 은 #1962(설정 Nav3 이관) 위에 쌓여 있고, #1962 는 설정 메인 사후 전달 조건 진입 경로의 PM 답을 기다린다: https://www.figma.com/design/UP9ZR186jHvRBicjA2SOea/?node-id=4327-64430#1923797606

그래서 사슬 13건을 함께 닫는다. 브랜치와 승인 리뷰는 그대로 남아 있고, 답이 오면 그 답을 근거로 #1962 부터 다시 열어 같은 순서로 올린다. 코드가 틀려서 닫는 것이 아니다.