|
|
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 |
|
|
|
57950a86db
|
fix: 集群日志重复条目 — 本地 Append 同步推进 Synced 水位
根因: Append 只推进 Seq 不推进 Synced。本地追加 seq=N 后 Synced 落后，
下一轮收到对端全量附带(含自己的 seq=N)时 ApplyDelta 视为未见过而再次追加
→ 审计日志出现同 seq 重复行（实测 .30 出现 seq=12/13/14 各两条）。
修复: Append 将 Synced 一并推进到新条目 seq——本地条目天然已同步，
对端回传的同一 seq 被 watermark 幂等跳过。
测试: TestLocalAppendNotDuplicatedByPeerFullLog
实测: 三台各触发 stop+start 制造多条事件 → 三台均 26 条 / 唯一seq 26 /
重复 0 / 水位一致 (seq=26)
|
2026-08-26 13:30:12 +08:00 |
|
|
|
ef98d9dca1
|
feat: 审计 CSV 导出 — 用户/API Key/集群操作日志一键下载
新增端点 (read 级, 审计 viewer 角色即可导出):
- GET /audit/users.csv: 账号清单 + 最后登录时间
- GET /audit/apikeys.csv: 密钥清单 (前缀+scope+最后使用+过期)
- GET /audit/cluster-log.csv: 令牌环操作日志时间线
(seq/time_utc/node/kind/detail/data_json 六列, detail 为人读摘要,
data_json 保留无损原始载荷)
安全设计:
- RFC4180 转义 (引号/逗号/换行)
- 公式注入防御: =/+/@/tab/- 开头单元格加 ' 前缀
- ISO8601 UTC 时间戳, Excel 直接排序
- 明文密钥不可逆, 仅导出展示前缀
前端:
- UsersView: 账号表/API 密钥表各加「⤓ 导出 CSV」按钮
- ClusterView: 日志导出下拉新增 CSV 选项 (走服务端生成)
- api.ts: downloadAuditCsv() 统一下载管道
测试: csvEscape 全用例 / users+apikeys CSV 内容断言 / 未认证 401
|
2026-08-24 22:53:52 +08:00 |
|
|
|
bf602016b4
|
feat(web): cluster page shows token ring — ring topology/leader/load, pending tasks, active forward topology with owner, incremental log sync view (e2e verified)
|
2026-08-18 09:13:20 +08:00 |
|
|
|
e59feb82c1
|
feat(M6): token-ring incremental log sync — append-only op log, delta rides token round-2, nodes converge on identical history (e2e verified join events)
|
2026-08-18 08:59:59 +08:00 |
|
