登录态和重试逻辑 review 和重构讨论

[HarlonWang]

[HarlonWang]

已由 #113 落地，收尾记录一下结论。

问题实质

不是「401 重试有 bug」，而是这套机制的成本全压在调用方身上。要正确用上 authorized {}，接入方得同时记住四件事，而编译器一条都拦不住：

1. 必须包一层 authorized {}
2. 必须保证 401 以异常形式冒出来（返回值吞掉状态码就失效）
3. 必须把副作用挪出重试块（重试重跑整个 lambda）
4. 必须理解返回 T? 里 null 的三种含义被压成了同一个值

结果如实反映了这一点：10 个调用点里 ChatApi 两处、MainActivity 两处直接绕开，4 个收藏写接口把 401 吞成 false、刷新从来没触发过。

做法

改用 loginbase-kt README「接入指南」第 2 步的接法：client 级 Auth 插件统一承担带 token、认 401、单飞刷新、重试一次。业务代码不再经手 token。

// 之前
authManager().authorized { api.fetchSubscription(it) }?.subscription
// 之后
api.fetchSubscription().subscription

TrendingApi 11 个方法签名去掉 accessToken 参数，authorized 与 cause 链回溯一并删除，三个 client 都装上插件。净变化 +439 / −385。

几个关键决策

• 不动 loginbase-kt：库的边界按业界共识划得是对的。它 docs/design.md 第 3 节论证了收整个 HttpClient 会撞两颗雷——Auth 插件在 401 回调里调 refresh() 而当前协程已持有单飞锁（Mutex 不可重入 → 永久挂起）、HttpRequestRetry 把 1 次刷新放大成 4 次撞穿救活护栏。
• GithubApi 不纳入：GitHub OAuth App token 永不过期，那里的 401 是「用户撤销了授权」，走 refresh 是错的。
• 顺带关闭 chat: token 过期后聊天直接失败——1d74f4f 引入 401 重试时漏了 chat 模块 #100：chat 模块此前完全没有 401 重试，它诊断的两个「authorized {} 套不上 chat」的理由（匿名端点会被短路、ChatException 不是 ApiException），在插件方案下不需要任何特判就消解了。

一条值得记的前提

整个方案依赖「ktor 只在装了多个 provider 时才要求 401 响应带 WWW-Authenticate」（Auth.findProvider 的 candidateProviders.size == 1 分支）。我们后端的 jsonError('Unauthorized', 401) 不带该头。这条已用单测钉住，并在真机 + 生产后端上实测通过。

验证

单测 269 个全绿；真机（Pixel_9_2 + 生产后端）验过：令牌失效后账户页与聊天页均静默刷新重试、用户无感；两条请求同时 401 只发一条 /auth/refresh；全程无 invalid_refresh_token。

auth-regression-checklist.md 已按新行为校准（D5 拆成同时/错开两条、新增 D8 聊天场景、G2 结论反转、删掉「副作用挪出重试块」那条已消失的约束）。

有意留下的

登出后账户页会残留上一账号的 GitHub 计数/热力图/事件流（refreshInternal 用的是 .copy()）。这是既有缺陷、非本次引入，触发需要「会话被远程撤销 + 客户端当时不在运行 + 冷启动进账户页」，且登录后即自愈，评估后决定不在本次处理。