5 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	041cc04dd6	fix(cluster): revoke 在无 topology 条目时静默失效 + 停用状态跨节点不同步 ... 上一提交（46e8bc3）上线后实测：`.106` 重启后，被用户停用的 `minecraft` worker **仍然被拉起**。继续挖出两处，均为静默失效型。 ## 1. Handler.Revoke 被 RemoveTopology 的返回值挡住了 if claimed.Revoke { if e.state.RemoveTopology(...) { // ← false 时整个块跳过 if e.Handler != nil { e.Handler.Revoke(...) } } } 停 worker 的唯一动作被关在「topology 里确实有条目」的条件里。而 RemoveTopology 对**不在 topology 的转发返回 false** —— 也就是说，越是 需要清理的僵尸转发（条目已丢、worker 还在），revoke 越是完全不做。 这正是 minecraft 的处境：停用请求到达时它已不在 topology ⇒ 返回 false ⇒ Revoke 不执行 ⇒ worker 永远不停 ⇒ 每 33 秒刷一次 connection refused。 修法：停 worker 与摘条目是**两件独立的事**，条目不在也照样停。 （审计日志 forward.remove 仍只在真的摘掉条目时写，这是对的。） ## 2. 停用状态是节点本地的，从不跨节点同步 `links` 表每节点各一份。实测同一时刻 `.60` 记 disabled=1、`.106` 记 disabled=0 —— 因为只有收到停用请求的那个节点写了 store，而**持有 worker 的 owner 往往是另一台机器**，它的副本仍是"启用"。Claim 只读本地 store ⇒ owner 认为该转发是启用的 ⇒ 又被拉起。 修法：task 已携带 Disabled，以它为准，RevokeFn 在本节点把它落库 （已有行改写；没有行则补一条 disabled 记录，防止日后在本节点被 claim 时复活）。 ## 测试 - TestRevokeIdempotent 原先只断言"不 panic"，正好漏掉这个 bug —— 它 允许「Handler.Revoke 从不调用」通过。现补上断言：拓扑里没有条目时 **仍必须调用** Handler.Revoke。 - 验证该测试有效：把 `&& removed` gate 加回去 → 如期变红；还原后变绿。 go build / go vet / go test ./... 全绿，gofmt 干净。	2026-09-26 10:05:55 +08:00
jianf	eda9bb9597	feat: cluster reliability (leader failover, crash rejoin, key exchange) + auth/users + canvas/forwards enhancements + comprehensive README + API docs ... - Cluster: forwardToNext offline detection (leader+non-leader), WatchLeader 1s heartbeat fallback, 409 for standalone nodes, Node.NodeKey key exchange via token ring, ClusterPeers persistence + auto-rejoin, Forward delegates to forwardToNext (bugfix) - Auth: Basic Auth (flag-creds fast path) + bcrypt users (admin/viewer) + Bearer API keys (read/write/admin scope) - Frontend: UsersView (accounts+API keys), ClusterView (ring/nodeKey/tasks/topology/log), StatusView (group management, per-proxy status), CanvasView (edge toggle/group), PortEdge (disabled/group labels) - API: handlers split (canvas/forwards/users/logs), canvas export/import, forwards group start/stop/assign/delete, cluster endpoints - Docs: comprehensive README rewrite (all flags/APIs/auth/cluster), docs/cluster-api.md (cluster management API reference) - Deploy: run-cluster.sh now 4-node ring + 1 isolated standalone, test-forward.sh updated for 4 nodes - Removed plan.md (design notes consolidated into README + API docs)	2026-08-19 21:09:24 +08:00
jianf	b518a13446	feat: Phase C 完成 — ModelRouter 风格 UI 重设计 + 模拟 frps 测试 + lastSync 修复 + 集群作坊搭建 ... - 主题: sakura×frost 玻璃拟态 (theme.css) + SCSS 变量重映射 - 侧栏: 玻璃侧栏 246px + 渐变品牌区 + 面包屑导航 - 状态页: 玻璃 KPI 卡 + 远程节点/本地服务卡片网格 - 集群页: 英雄玻璃卡 + 横向环拓扑链 + 待办命令/活跃拓扑/日志区 - 令牌环: 新增 lastSync 上次同步时间替代周期计数 - 模拟 frps: frps2/frps3 容器 + test-forward.sh 全链路验证脚本 - 修复: BinaryPath 空导致 worker 不启动, 撤销仅撤第一个 link, 任务复活风暴 (published 追踪)	2026-08-18 23:38:20 +08:00
jianf	40980944e5	feat(M6): localOnly forward option (loopback→LAN rewrite for cluster, local direct), canvas diff-based create/revoke commands, revoke task semantics, topology derived canvas on sync nodes, LAN addr helper	2026-08-18 09:44:38 +08:00