ModelRouter

mirror of https://gitcode.com/JianFeeeee/ModelRouter.git synced 2026-11-07 09:47:23 +00:00

Files

JianFeeeee 0f83fc048a fix(channels): 账号顺序的确定性 + reorder 真正改内核源顺序

## ① 真实缺陷：同秒创建的账号，顺序**不确定**
`poolList` 的排序键是 `priority` 降序 + `createdAt` **升序**，而 `createdAt` 是
**秒级**（`os.time()`）⇒ 同一秒建的两个账号比较**相等** ⇒ 相等时 `table.sort`
的结果取决于 `pairs()` 遍历顺序 —— **不确定**。
实测：按 a,b,c 顺序建三个账号，`poolList` 回的是 `[a,c,b]`。

后果不只是"顺序看着乱"：**源注册顺序 = poolList 顺序 = 内核尝试顺序**
⇒ 同秒创建的账号里"先试哪个"是随机的（buddy 15 天窗口下影响先用谁的积分），
且可能每次进程重启都变。修法：加 **id 作稳定兜底键**（唯一且不变）。

## ② reorder 只改字段、不影响路由
`account_reorder` 只设 `acct.priority`，**不重注册源**。而一个源一旦注册，
顺序就固定了 ⇒ 重排对实际路由**毫无影响**（"优先账号"并不会先被试）。
修法：重排后按新顺序**整体重放一遍** `syncAccountSource`
（remove+add 会把源移到最后，故必须整体重放，只补被移动的那几个相对顺序仍不对）。

## 判据（2 条 + 变异 2/2）
internal/core/channels_reorder_effect_test.go
- reorder 必须真的改变**内核 list_sources 的顺序**（判据看内核里的真实顺序，
  不是 pool 里的 priority 字段）
- 同优先级 + 同秒创建时，顺序必须由**稳定键**(id)决定（字典序）

★ 两个判据第一版**都不咬变异**，原因各异，值得记下：
1. reorder 判据：初始顺序恰好**已是**目标顺序 ⇒ 无法区分"重排生效"与"本来就对"。
   改法：显式断言初始顺序、并让目标顺序与之**相反**。
2. 确定性判据：我直接断言 `account_add` 之后的顺序，而 `account_add` 是
   **直接同步自己那一个账号**（源顺序 = add 顺序），**走不到排序逻辑** ⇒
   测的其实是 add 顺序。另外**多轮 in-process 反复构造也测不出** ——
   `pairs()` 顺序在同一次进程里是稳定的，只有跨进程/跨分配才变。
   改法：走**批量重注册**路径（`__resync_sources_probe`）+ 显式把 priority 拉平
   构造"排序键完全相同"的场景，再断言字典序。

## 顺带修的判据自身问题
- `sourceOrder` 原来顺带调了 `__sync_source_probe`（内部 remove+add）⇒
  **"测之前先动了被测对象"**，顺序忽而两个忽而一个。改为**只读**。
- 探针取内核返回时按 `{sources:[...]}` 取，而 `actionListSources` 返回的是
  **裸数组** ⇒ 恒得空列表。
- 夹具漏授 `add_source` 内核权限 ⇒ 源一个都不出现（内核会明确拒绝，只是我
  没看返回值）。子测试才能拿到独立的 env 与目录（同函数内 `t.Setenv` 只生效一次）。

2026-10-16 09:36:02 +08:00

adapters

feat(opencode): Zen 免费层可用 —— 门禁四要素 + id 公式逆出

2026-10-15 20:30:33 +08:00

plugins

fix(channels): 账号顺序的确定性 + reorder 真正改内核源顺序

2026-10-16 09:36:02 +08:00

adapter_opencodezen_live_test.go

feat(opencode): Zen 免费层可用 —— 门禁四要素 + id 公式逆出

2026-10-15 20:30:33 +08:00

adapter_opencodezen_test.go

feat(opencode): Zen 免费层可用 —— 门禁四要素 + id 公式逆出