|
|
662f8f02b6
|
fix(channels): 商汤扫码链路重建 + 双区登录 + 凭据过期口径 + 四条老化判据
① 商汤（Raccoon）扫码「链接无效」——两个真根因
- 登录页 /login/mp 已被站点删除（Next 路由 404，实测只有 404 页）；
- 旧实现本地随机造 qrcode_code，而上游早已不认自造码：旧端点
/api/web/auth/v1/login_with_qrcode_code 对任意 code 恒回 pending
（服务端没有该会话）⇒ 扫码永远完不成，账号一直是空凭据。
修法：改为上游现行 IAM 流程（逐行对齐其网页客户端 auth chunk）——
POST /api/iam/v1/auth/mp/qrcode 建会话 → 链接用
/login?code=…&appname=…&source=platform（实测 200 + 微信扫码面板）
→ 轮询 /api/iam/v1/auth/mp/qrcode/login（IAM code:"OK" 与旧 code:0 都认）。
服务端建码失败才退回旧本地码并打 warn。UI 对扫码流程改文案为
「用微信扫码」（原本文案会让人以为点开就自动登录）。
生产实测：链接 HTTP 200、轮询回 pending（会话真实存在）。
② 双区登录（P7）
- 凭据增加 region（intl|cn，缺省＝历史行为）；start_login 接受 region，
会话按区域选端点，完成登录写进凭据；
- CodeBuddy：cn=copilot.tencent.com（platform=ide）/
intl=www.workbuddy.ai（platform=workbuddy-ai，X-Domain、
X-Product-Code、UA 按区域；实测 auth/state 回 200 信封）；
- Qoder：intl=openapi.qoder.sh+qoder.com（client_id e883ade2-…）/
cn=openapi.qoder.com.cn+qoder.cn（client_id 不同 732aef47-…，照参考
QODER_CN）。CN 无公开 chat 端点 ⇒ CN 只做登录/领取；
- UI：buddy/qoder 详情页增加「＋国际区」按钮。
③ 凭据过期时刻的时区口径（P6 真根因）
credentialExpiresAtMs 把 ISO 过期时刻按本地时区解析，而 codearts 给的是
UTC ISO（2026-10-19T16:42:43.06Z）⇒ 本机 +08 下过期时刻虚早 8 小时 ⇒
refresh_creds 每 30 分钟都判"已过期"并对华为云真打一次 STS（token 本还有
23 小时寿命）。改为按声明时区解析（Z / ±hh:mm / 无后缀=UTC 三种形态同一
epoch），补 TestCredentialExpiresAtMsParsesISOAsUTC。
④ 四条老化/假红判据
- TestCreditsPoolReason*：account_add 触发的选号会用构造期默认余额 (0,0)
先查一次并缓存 60s ⇒ 之后改假上游读不到（"余额 100 却报 exhausted"）。
harness 改余额后清 TTL 缓存（__ttl_reset_probe，与生产同一实现）。
- TestAccountReorderActually... / TestPoolListOrderIsDeterministic：随
「一通道一源」失效（按 channels-buddy-<acct> 过滤恒得空）。改写为——
重排必须切换服务账号（新增 __chosen_account_probe），顺序确定性改为断言
选号顺序（__rank_accounts_probe）由 id 稳定决定。
- channels.lua 顶层 local 余量：区域表与 5 份适配器源码常量收进 plugin.K
（TestChannelsLuaHasLocalHeadroom 需要 ≥10 槽位）；ZCode 适配器源码里的
CLI_PREFIX 必须留在源码内（适配器沙箱没有 plugin 全局）。
⑤ 错误文案
openai_error 增补腾讯 codebuddy 三层嵌套 {error:{data:{code,msg}}}：实测
429 code=14018「额度已用尽」此前落到"不识别"，客户端只看到通用文案。
验证：core 434s 全绿、lua 62s 全绿、provider 全绿；生产已部署并实测
raccoon 链接 200 / trae 非流式 200 / zcode 适配器加载。
|
2026-10-20 08:27:28 +08:00 |
|
|
|
252e3486bd
|
fix(channels): 凭据续期此前是假的 —— 现在真发请求、真回写、真报错
★ 修的是一个**比不做更坏**的缺陷：`account_refresh` 只重同步了源、**一个换
token 的请求都不发**，却恒返回 `ok:true` ⇒ `refresh_creds` 打出
「凭据已续期 N 个」而实际什么都没续。日志在说谎 —— 排查时会去看网络、看上游，
而真因是根本没有这段代码。这是本轮第三次遇到"静默恒真"（前两次是
`account_test` 恒返回 ok、`pcall` 只取 ok 不看返回值）。
实现要点（每条都是参考踩过的坑）：
- **各平台续期字段名不同**，写错服务端只回泛化的认证失败、极难定位：
Cline 是**驼峰** `refreshToken` + `grantType`（不是 OAuth 的
refresh_token/grant_type）、响应套 `{success,data}` 信封且字段是**驼峰**
`accessToken`；Google 走标准 `refresh_token` 表单编码 + client_secret。
- **Google 偶尔轮换 refresh_token**：响应给了新的**必须回写**，否则下次用旧的
直接失效。
- **`expires_in` 是相对秒数** → 必须换算绝对时刻，否则每轮都判定"快过期"重续。
- **按需续期必须回写索引的 expiresAt**（照 expiry-sync）：不回写会出现
「显示已过期、但发消息正常」的数据源分叉。
- 失败**如实回错**（HTTP 状态 / `error_description` 都带出来），但仍重同步源 ——
旧 token 可能还没真过期，不该因续期失败就撤源。
- `refresh_creds` 的计数判据改用 `refreshed`，**不是** `ok`：
`account_refresh` 在"平台未声明续期方式"时也回 ok:true（源照旧同步），
用 ok 计数就会把"没续"算成"续了"—— 这正是日志说谎的机制。
判据（必须**看到真请求**，否则还是在验一个恒真的返回值）：
1. 假上游断言**真发出 1 次请求**（原实现是 0 次却报成功）、路径正确、请求体是
驼峰 `refreshToken`/`grantType`、新 token 与轮换的 refresh_token 都落进凭据；
2. 401 时**绝不报 refreshed=true**，且错误含 HTTP 状态；无 refresh_token 时
提示"需重新登录"；
3. `expires_in:7200` → 凭据里是**绝对** expires_at（不是 7200），且
**账号列表**（不是保险库探针）里 read 到索引 expiresAt 已回写。
另修两个同处踩过的坑：`credentialIsRefreshable` 定义在使用点**之后**
（Lua local 前向引用，第 10 次）、`urlencode` 不存在（Google 表单编码需要）。
回归：9 个包全绿。
|
2026-10-14 16:46:43 +08:00 |
|
