fix(edge): events 正确性批 2——闸门遗弃轮次永久卡死总线 / 截断短读丢最新事件 / 确定性 persist 失败仍烧退避梯

[DeliciousBuding]

这是什么

三条同包（edge-server/internal/events/）正确性缺陷，都是 #2234（seq 顺序不变量）落地后由主机侧复审与 lane 移交清单挖出的。关联：#2154

fix(edge): events 正确性批 2——闸门遗弃轮次会永久卡死总线 / 截断短读丢掉最新事件 / 确定性 persist 失败仍烧退避梯 (#2154)

三条同包缺陷，都是 #2234（seq 顺序不变量）落地后由主机侧复审与移交清单挖出的。

一、闸门遗弃轮次 → 总线永久卡死（#2234 引入的新失败模式，主机侧复审发现）
#2234 的顺序门要求「拿到 seq 的那个 publisher 必须消费掉自己的轮次」。
deliverInSeqOrder 的 defer 覆盖了函数内部的 panic/Goexit，但 seq 分配到进闸
之间还有一段**没有任何守护**的代码：persistWithRetry（走 EventLog.Append，
含 37.5MiB 级读写与截断）与失败时的 slog.Error。而 Publish 的调用方是
safego 守护的 goroutine（orchestrator dispatch、lifecycle 回调队列），所以那里
的 panic 会被**上层恢复、进程继续活着**——但 wireNext 永远停在该 seq 之前，
之后每个 publisher 都停在 `for b.wireNext < seq { Wait() }`，再没有人能
Broadcast。一次丢事件升级成**重启前全量静默丢事件**，比顺序门要修的乱序更严重。
红证据（两条，均实测）：
  - `goroutine 7 [sync.Cond.Wait]` 永久停在 `deliverInSeqOrder(seq=2)`，
    `panic: test timed out after 15s`（seq 1 的轮次被恢复掉的 panic 遗弃）；
  - 快速失败形态：`bus wedged after a recovered panic between seq assignment
    and the wire gate: wireNext never advanced, so every later publisher parks
    forever in sync.Cond.Wait`。
修法：Publish 在 seq 分配后立刻挂一个 defer，未被 deliverInSeqOrder 接管时调
abandonGateTurnLocked(seq)；轮次已到就当场消费，没到就记进 wireAbandoned，
等闸门走到时由 advanceGateLocked 级联跳过（跳过时删除，map 由"尚未被走到的
遗弃量"限界）。**不在 panic 展开的 defer 里 Wait**——那会把恢复路径变成新的
死锁面。
自陈：我的第一版 advanceGateLocked 在"无遗弃"的常规路径上 `return` 而漏了
Broadcast，直接复现同类卡死，被既有 TestBusConcurrentPublishSubscriberIntegrity
挂住（2 分钟超时）抓到；已修并把原因写进注释。

二、truncateLocked 短读 → 丢掉最新事件（数据丢失级，#2234 移交，主机侧已核实）
截断路径 seek 到 -keepBytes（= maxSize*3/4，50MiB 默认即 37.5MiB）后**只做一次**
l.f.Read(buf)，随后 Truncate(0) 已经毁掉原文，却只回写 buf[start:n]。
read(2) 对普通文件返回少于请求的字节数是完全合法的（大读、信号中断、网络/
overlay 文件系统），os.File.Read 一次 syscall 对应一次调用 → 短读时**未读到的
那段正是保留窗口的尾部，也就是最高 seq、最新的事件**。
同函数第二个反模式：`readErr.Error() != "EOF"` 用字符串比对判 EOF，包装过的
EOF 会漏判。
修法：抽出可注入的 readRetentionWindow(io.Reader, int64) 循环读满，EOF/
UnexpectedEOF 视为"文件比窗口短"（返回已读字节，不算失败），其余错误照旧计入
truncateFailures；errors.Is 取代字符串比对。
红证据：注入每次只返回 1/3/7/64 字节的 short reader →
`chunk=1: read 1 of 1520 bytes — a short read silently drops the newest,
highest-seq tail of the retention window after Truncate(0) already destroyed
the original`。
诚实标注：真文件端到端那条（TestTruncateLocked_KeepsNewestEventsEndToEnd）
修前修后**都绿**（本机 ext4 这个尺寸不会短读），它是回归钉子不是红证据；
红证据只来自注入的 short reader。

三、确定性 persist 失败仍烧退避梯（#2234 移交，主机侧复核后接受）
persistWithRetry 对 json.Marshal 的永久性失败（payload 里有 chan/func）照样
重试 3 次并睡 2+4+8=14ms；而顺序门把"慢 persist"从单个 publisher 的延迟变成
**总线级延迟**。
修法：EventLog.Append 把 marshal 失败包成 errUnpersistableEvent，
persistWithRetry errors.Is 命中即立即返回不睡；瞬时错误仍照旧重试。
红证据（临时撤回分类分支复现，已复原）：
  `a deterministic persist failure burned 14.73489ms`
  `persistFn was called 4 times, want exactly 1`
另一方向也钉住：TestPersistWithRetry_TransientFailureStillRetries（修前修后均绿，
防止"分类"退化成"永不重试"）。

门禁（全部跑在本 HEAD）：
- edge go build ./... / go vet ./... 干净；gofmt 净
- go test ./internal/events/ -count=1 → ok 1.5s
- go test ./internal/events/ -race -count=3 → ok 16.0s，无 DATA RACE
- golangci-lint run ./internal/events/... → 0 issues
- verify-edge-lint-ratchet.py → PASS（9 findings，全在基线，未新增指纹）
- gosec -fmt=json ./... | verify-gosec-gates.sh → CLEAN
- verify-doc-ssot / verify-conventions rc=0；git diff --check 干净
证据等级：L0（单测 + -race + 静态门禁）。未做真实 :3210 + SSE/WS 客户端的
端到端乱序/截断观测，也未量化闸门 head-of-line 的 p99 尾延迟。

门禁汇总

门禁	结果
edge go build ./... / go vet ./... / gofmt	干净
go test ./internal/events/ -count=1	ok 1.5s
go test ./internal/events/ -race -count=3	ok 16.0s，无 DATA RACE
golangci-lint run ./internal/events/...	0 issues
verify-edge-lint-ratchet.py	PASS（9 findings 全在基线，未新增指纹）
gosec | verify-gosec-gates.sh	CLEAN
verify-doc-ssot / verify-conventions / git diff --check	rc=0 / 干净

证据等级：L0（单测 + -race + 静态门禁）。未做真实 :3210 + SSE/WS 客户端的端到端观测，也未量化闸门 head-of-line 的 p99 尾延迟。

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: 83bd1efb-01b5-4407-9159-fe4f93657a7b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[DeliciousBuding]

追加：首轮 CI 的 Native Windows Go (edge-server) 红已定位并修复（commit 40bb5708），而且它揭出一个先于本 PR 的已发布平台缺陷

失败点不是本 PR 的新逻辑，而是新断言显形了一个既有缺陷：

ERROR event log truncate Truncate(0) failed path=...\truncate-replay.jsonl
      error="truncate ...: Access is denied."
--- FAIL: TestTruncateLocked_KeepsNewestEventsEndToEnd
    log grew to 45692 bytes with maxSize 4096

• 报错同时出现在既有测试 TestEventLogIndexSurvivesTruncation 的日志里 → 缺陷先于本 PR。
• 根因：NewEventLog 以 O_APPEND|O_CREATE|O_RDWR 打开日志（eventlog.go:102），Windows 对 append 模式句柄拒绝 SetEndOfFile，于是 l.f.Truncate(0) 每次都失败；Linux 接受同一调用，所以在 Linux 开发面与 Linux CI 上完全不可见。
• 影响面（已核实 Edge 真的在 Windows 出货，不只是跑 CI）：release.yml:109 构建 agenthub-edge-<ver>-windows-amd64.exe，:203 作为 Tauri sidecar agenthub-edge-x86_64-pc-windows-msvc.exe 打进桌面安装包，:262 进 portable 包 ⇒ 每台 Windows 桌面安装的事件日志永不截断、无界增长，现场线索只有每次 Append 的一条 error 日志与 edge_event_log_truncate_failures_total。

修法：截断与重写改走独立 O_RDWR 句柄（Go 以 FILE_SHARE_READ|WRITE|DELETE 打开，第二句柄合法；重写仍在 l.mu 内；append 句柄语义不变，rebuildIndexLocked 末尾仍 seek 回 EOF）。没有动 O_APPEND——它给的是并发写入者只追加的保证，为截断牺牲它不划算。代价是每次截断多一次 open/close（约每 25k 事件一次）。

测试也强化了（跨平台，不加 skip）：原来只查 MaxSeq/ReadFrom，Windows 上「截断失败但索引还在」能蒙混过关；现在同时断言 fi.Size() <= maxSize 且 log.truncateFailures == 0，即"截断必须成功，不是尝试过"。

诚实边界：Windows 侧结论只能由 CI 的 Native Windows Go (edge-server) 证明，本机无 Windows，不冒充已验证。Linux 侧本 HEAD 重跑：go test ./... 34 包 ok、-race ok 6.7s、golangci-lint ./internal/events/... 0 issues、ratchet PASS(9 全基线)、git diff --check 干净。