2 Commits

Author	SHA1	Message	Date
JianFeeeee	1c835425de	feat(cluster): 停用改为「标记」语义，让 disabled 真正随令牌环跨节点传播 ... 承接用户提问「设计上停用不是本来就会跨节点传输吗」——核实结论：结构上确实 如此（TopoEntry.Link 是完整 store.Link，整个 State 随 token 每轮广播），但 实际路径断了。断点正是「撤销会删掉 topology 条目」：条目是 flag 的载体， 删了就无处传播，于是停用只能靠一次性 revoke 任务投递给 owner，**owner 当时 不在线就收不到**（实测 .60 记 disabled=1 / .106 记 0，就是这么来的）。 ## 改为标记而非移除 撤销不再 RemoveTopology，而是 UpdateTopologyDisabled(true)，条目保留、 Link.Disabled=true、Active=false。Active 正是为此存在：OfflineReassign() 只处理 Active 条目，所以停用的转发在 owner 掉线时不会被重新排队。 - 新增 UpdateTopologyDisabled / TopologyDisabled（照 UpdateTopologyGroup 的桥） - 新增 store.ReconcileLinkDisabled 作接收端：adoption 时把环上的 flag 落进 本地 store；本节点没有该转发时补一条 disabled 占位行（否则日后在本节点被 claim 会复活），enable 则不建行 - SetTopologySync 由单向（store→环）扩为双向：群组仍上行，disabled 下行 - AddTopology 的 Active 跟随 Link.Disabled（原本硬编码 true，认领一个停用 转发就会复活它） - 审计日志细分 forward.stop / forward.start，与 forward.remove 区分 ## 语义变更带出的两个新问题（都已修） 1. **「启动」这条路断了**。条目保留 ⇒ SubmitTask 被去重挡下，而认领路径的 duplicate-claim 防御又会丢弃「已有 owner」的任务 ⇒ 重启任务发不出去，owner 永远收不到，转发**能停不能起**。 修：新增 Task.Restart 这一独立任务类型 + SubmitRestart + Handler.RestartFn， 显式绕过 duplicate-claim 防御并原地复活（不重复建条目、不重跑 claim 簿记）。 SubmitTask 的守卫同时从 HasTask 收窄为新的 HasActiveTask（跳过 disabled 条目 与撤销任务）；saveCanvas 的判断相应改用 HasActiveTask，避免每次保存都对 已标记的转发重复发撤销。 2. 原本两处 RemoveTopologyEntry 调用（ClaimFn/RevokeFn 的 disabled 分支）在 新语义下会把本该保留的条目删掉，改为 UpdateTopologyDisabled。 ## 测试（每个都做了「回退修复行→必须变红→还原变绿」双向验证） - TestStoppedTopologyEntrySurvivesAdoption —— 离线成员也能学到停用， 一次性 revoke 任务永远做不到这一点 - TestStoppedForwardNotRequeuedOnNodeDeparture / TestAddTopologyRespectsDisabledFlag —— 标记而非删除为何安全 - TestSubmitTaskNotBlockedByStoppedEntry / TestSubmitTaskStillDedupesActiveForward - TestRestartTaskBypassesDuplicateClaimGuard / TestRestartFlagSurvivesTokenSerialization - TestStopThenStartPublishesRestartTask（HTTP 端到端，断言**任务真的发出**） - TestReconcileLinkDisabled*（store 侧三条） ★ 两次踩到**假绿**：第一版只断言 store 层（newTestHandler 的 Ring 为 nil， 坏掉的路根本没执行）；第二版在 re-enable **之后**才调 SubmitTask，此时新旧 谓词结果相同，测不出差异。都是靠「回退修复行看是否变红」抓出来的 —— 这个 双向验证已经是本项目的固定动作。 go build / go vet / go test ./... 全绿，gofmt 干净。	2026-09-26 10:44:04 +08:00
JianFeeeee	46e8bc3703	fix(cluster): 停用的转发会在重启后自己复活 + 令牌轮转日志刷屏 ... 从线上三节点（192.168.2.{30,106,60}）的日志里挖出四个问题，本轮修三个。 ## 1. 停用的转发会复活（功能性缺陷，实测仍在发生） 线上现象：`minecraft` 在 store 里 disabled=1，worker 却仍在跑，今天 09:46 还在刷 `connect to local service [192.168.2.60:25565]: connection refused` —— 对着一个用户刻意没启的本地服务死刷。同时三台 logs 里躺着 13956 / 3769 条 `proxy [x] already exists`，每 33 秒一轮。 四处叠加导致： - stopForward 先读 link，再 SetLinkDisabled(true)，然后把**改之前**的 副本交给 RevokeTask ⇒ published task 带 disabled=false（实测 id/flag 都对不上：topology 里 link.id=223，store 里同一行是 199） - ClaimFn **无条件** SetLinkDisabled(...,false)。原意是"重新认领时清掉 停用标记"，但启动 reconcile 只要 worker 不在就重新 Claim ⇒ 每次重启 都是"先清标记再起 worker" - RevokeFn 停了 worker 却**没删 topology 条目**，条目活过 worker - 于是下次重启 reconcile 看到"owned 但 worker 不在"→ 再次 Claim → 死循环 修法（把 disabled 的所有权交回两个用户动作）： - Claim **只读** disabled 决定要不要起 worker；为 true 时连 topology 条目一起摘掉，绝不复活 - 启动 reconcile 先按 store 跳过 disabled 的条目（省掉无谓的 claim→skip 往返） - RevokeFn 除停 worker 外，同时 RemoveTopologyEntry —— 撤销必须是 完整退役，不能只是"停一下" - stopForward 把 Disabled=true 随 task 发布出去，让持有该转发的节点 即使本地 store 行陈旧也能判断这次停用是用户主动的 ## 2. 令牌轮转日志零信息量却占满磁盘 每轮固定 3 行（OnToken cycle=N / forward cycle=N / token-send -> 200）， 2 轮/秒，实测本机 **355 行/分钟、7 天 357 万行**，把真事件全淹了。 同一份信息（cycle / lastSync / roundDelayMs / 成员存活）本来就能从 GET /api/manager/cluster/ring 结构化拿到。 加 W4F_DEBUG 开关（沿用项目既有 W4F_ 前缀约定）：稳态三行降级为 debug、 默认关闭；**失败路径一律保留** —— 发送失败、陈旧令牌、非 2xx 正是别人 grep 的对象，静音它们是坏交易。实测同样 12 秒：36 行 → 4 行。 ## 3. Link.ID 在 ReplaceLinks 之后必然失效 ReplaceLinks 是 DELETE + 重新 INSERT，sqlite 给每行**新的自增 id**。 任何在改写前捕获的 Link（典型：随 token 环跑的 Link）手里的 id 要么查无 此行，要么命中另一条转发 —— 实测捕获 alpha id=1，改写后新表是 3/4/5， GetLink(1) 直接落空。 新增 LinkByTriple(local, remote, port) 按自然键查（业务代码本来就一律用 这个三元组标识转发），并把 claim/reconcile 切过去。查无行返回 (Link{}, false, nil) 而非 error：新建的转发没有行，应当照常启动。 ## 4. homeagent_device 孤儿（已澄清，非独立缺陷） 它 disabled=1 且从不在 topology 里，是缺陷 1 的另一面（停用标记没进 token），随本次修复覆盖，无需单独处理。 ## 测试 新增 4 个测试文件，重点是**验证测试本身抓得住 bug**： - 临时回退 `ln.Disabled = true` 这行 → TestStopForwardPublishesDisabled- FlagInRevokeTask 如期变红，还原后变绿 - ⚠️ 第一版回归测试只断言 store 层，是**假绿**：newTestHandler 的 Ring 为 nil，RevokeTask 那条（真正坏掉的）路根本没执行。补了带 ring 的 newRingTestHandler，直接断言**发布出去的 task 上的 flag** - LinkByTriple 在 ReplaceLinks 前后保持稳定；GetLink(id) 的失效被固化成 一个可见的说明性测试 - 停用/start 往返、per-forward 停用不误伤兄弟转发 - 错误路径不静音、W4F_DEBUG 各种取值 go build / go vet / go test ./... 全绿，gofmt 干净。	2026-09-26 10:02:55 +08:00