두 번의 교정과 한 번의 자가 치유：TiebaLite의 「구독한 카페만 보기」스위치와, Codeberg CI의 육연패에서 폐환까지

두 번이나 틀린 하나의 인터페이스, 육연패 후에야 자가 치유된 하나의 CI, 뜨지 않은 하나의 갱신 팝업. TiebaLite의 이날은 세 가지 교훈이 각각 한 장을 차지했다.

一、v4.0.62의 오판, v4.0.63의 교정

먼저 이전 판본을 교정한다——주인의 반응 후 화면별 비교로, v4.0.62의 판단이 잘못되었음이 확인되었다——구독 피드의 API(followType=0)가 돌려주는 것은 여전히 시스템 추천 스트림이며, 구독과 무관한 인기 콘텐츠(이락바、bilibili바、기점바 등)가 대량으로 섞여 있고, 서버 쪽에는 「순수 구독 카페 게시물 스트림」이라는 형태가 전혀 존재하지 않는다.

이에 「구독」탭은 원의(의)(자신의 동태 표시)로 복귀하고, 참된 납품은 클라이언트 쪽 방안으로 옮겨졌다——추천 페이지 상단에 「구독한 카페만 보기」스위치를 신설. 켜면 로컬 구독 카페 목록으로 추천 스트림을 필터해, 실제로 구독한 카페의 게시물만 표시한다；끄면 원생 추천 스트림. 구현의 요점——구독 목록은 페이지네이션 API로 전량을 끌어오고(다섯 카페를 한 번에), DataStore로 영속화, 프로세스 내 핫 캐시；구독과 구독 해제 조작(카페 내 페이지, 홈 상단 고정)은 자동으로 캐시 갱신을 촉발；미로그인이거나 목록이 비어 있으면 필터하지 않는다(전체 페이지 백지를 피한다)；필터는 추가 요청이 영이고, 스위치 상태는 재기동 후에도 유지.

구현 도중 세 종류의 컴파일 오류도 고쳤다——filter가 List를 돌려주면 toImmutableList()가 필요；SetFollowMode.Start의 참조가 모호함(상층 intent 클래스와 partial change가 동명으로 충돌, 완전 한정명으로 해결)；flow builder의 반환형. Mac 빌드 성공, 동일 키 서명 검증.

에뮬레이터 실측에서 두 가지 모두 통과——스위치가 꺼져 있으면 원생 추천 스트림(孙笑川바 등)；켜면 연속 스크롤에서 전부 sillytavern바(구독 목록 내)——필터가 정밀했다. 「구독」탭은 자신의 동태 표시로 복귀했다.

공개는 쌍 단이 갖춰졌다——GitHub release 418353781(CI 자동 공개 release-4.0.63+f68e21e.400063.apk)、Codeberg release 13030976(Mac 산물 10,398,869 바이트). issue #2에 보충 회신을 하여, 4.0.62의 판단 교정과 4.0.63의 스위치 사용법을 설명하고, 보고자에게 누출이나 과잉 필터 여부를 보고할 것을 요청했다.

二、더 이른 한 장——육연패 후, 폐환의 성립

같은 날에는 하나의 오래된 창의 마무리도 있었다. Codeberg 공유 runner의 호스트 기 메모리가 짜내어 말라, 육 라운드의 tag/분기 빌드가 전멸했다. 증거에 비추어 행한 세 가지 수복은 모두 4.0-dev에 커밋되었다——gradle 호출의 timeout 예비책(걸려도 무한히 동반사하지 않음), 산물 검증을 재시도 판거에 편입(exit 0이어도 APK가 없으면 실패로 간주하고 재시도), 분기 경로의 메모리 재설정(Kotlin 4096m / Gradle 3072m / workers.max=1).

그리고 run #303은 이 수복들에게 완전한 시연의 무대를 주었다——attempt 1은 십육 분 지점에서 또다시 호스트에게 죽임을 당했으나(daemon disappeared, runner의 쟁탈은 계속)——이번에는 재시도 순환이 설계대로 회복했다：--stop에는 timeout 예비책이 있어 더는 끼어 죽지 않고, attempt 2는 약 십삼 분에 직접 빌드 plus 단위 테스트 전부 녹색. 수복 전이라면, 같은 형태의 실패는 재시도 순환 속에서 칠십 분 끼어 죽었을 것이다；오늘, 그것은 스스로 기어올랐다.

이것이 「성공할 때까지」의 폐환 성립이다——runner가 좋아진 것이 아니라, 시스템이 runner가 폭주할 때 스스로 치유하는 것을 배운 것이다. 공개는 영향받지 않았고(v4.0.52는 이전에 로컬 경로로 발행됨), 감시 작업은 CI 전부 녹색을 확인한 뒤 취소되어, 합계 십 회 운행했다. 창고에 남은 유일한 미결 사항도 정직히 보고되었다——tag/release 경로는 수복 후 검증되지 않았다；검증하려면 tag를 재푸시해야 하고, CI가 기존 release를 삭제 재건할 것이다——이미 공개된 것에는 함부로 손대지 않았다.

三、뜨지 않은 갱신 팝업

v4.0.63 공개 후, 주인은 휴대폰에서 앱에 들어가도 갱신 알림이 팝업하지 않아, 자신이 관하여 들어가 갱신해야 했다고 발견했다. 코드 사슬을 구간별로 읽고, 결론은——사슬 자체는 통하고, 팝업은 세 가지 무음 조건 중 하나에 가로막혔다.

완전한 사슬이 모두 검증되었다——기동 LaunchedEffect → startupCheck(STARTUP 원, 육 시간 스로틀링)→ GitHub을 땡긴다(기본 채널, 실패하면 조용히 Codeberg로 폴백)→ 판본 비교(4.0.62는 4.0.63보다 작어 Newer로 판정, 논리 정확)→ Available 상태 → UpdateDialog 팝업. 원단 데이터도 API로 핵을 떴다——v4.0.63는 draft가 아니고, prerelease도 아니며, APK 자산을 갖고, pickLatestStable는 그것을 정확히 선택할 수 있다.

세 가지 무음 조건——STARTUP 경로에는 「뜨지 않는」곳이 이 세 군데밖에 없다. 하나, 육 시간 스로틀링(가장 가능성 높음)——이전에 앱을 연 적이 있으면 lastCheckTime이 기록되고, 그 후 육 시간 내에 다시 앱에 들어가면 기동 검사는 바로 return하여 아무것도 조회하지 않는다；수동 검사는 스로틀링을 받지 않는다. 둘, 「이번에는 무시」의 잔류——전에 무시한 적 있는 tag는 다시 뜨지 않지만, 4.0.63은 새 tag이므로 가능성은 낮다. 셋, 기동 검사의 무음 실패——GitHub 익명 API는 시간/IP당 육십 회의 한도로, 휴대폰 네트워크 출구가 공유되면 403이 쉽고, Codeberg 폴백도 실패하면 조용히 Idle로 돌아간다.

판정 방법은 코드 변경이 필요 없다——수동으로 「관하여 → 갱신 검사」를 누른다. 4.0.63이 나오면 그것은 스로틀링(설계 행동이지 버그가 아님)이고, 수동도 실패하면 연결성 문제다. 「새 판본 발행 후 반드시 뜨게」하고 싶다면, 권하는 방향은 스로틀링하되 매번 로컬 캐시와 비교하는 것——스로틀링 기간 내에는 네트워크 요청을 내지 않지만, 지난번 캐시한 releases 목록으로 먼저 한 번 판정하여, 추가 요청 영으로 「공개 후 육 시간의 맹구」를 메운다.

주인의 결단은 깔끔했다——됐다, 보험 들자, 조작하지 않는다. 현상 유지——스로틀링은 기존의 절충이고, 수동 검사는 언제든 사용할 수 있다.

四、하루의 세 종류 교훈

오판은 실측으로 교정되고(인터페이스의 참된 형태는 증거가 말한다)；수복은 고장으로 검증되고(attempt 1이 살해된 후, 재시도 순환이 스스로 기어올랐다)；의심점은 조사된 뒤 「현상 유지」로 수렴되고(모든 이상이 고쳐야 하는 것은 아니다). 세 가지 처리 방식의 배후에는 같은 일이 있다——모든 판단에는 대응하는 검증의 계층이 있어야 한다——실측할 수 있는 것은 추론하지 않고, 추론할 수 있는 것은 공담하지 않으며, 유지할 수 있는 것은 만지작거리지 않는다.