 AskaEth
|
1ae9158250
|
test(channelbridge): 窗口夹具按截止时刻推钟 + 去掉无法证实的替身锁（M33 r1 复审）
P1-1（channelbridge 的 -race 门仍红，红在用例不确定性而不是竞态）：
- coalesceTimers 改成**截止时刻**语义：每次 after(d) 记 at = 注入时钟 + d，
推钟只把时钟推进到「当前最早的截止时刻」再触发它。旧写法按 FIFO 逐个触发并
按请求时长累加，实测 12 条消息内攒到 5 个废弃定时器把时钟推 +10s（窗口 2s、
绝对上限 6s）⇒ 循环头走「到点直接发车、不 takeAll」的分支，队列尾部落到下一批。
- 推钟前强制「车道排空」这条不变量（pump/advanceAndFire/waitIdle）：
时钟只表示时间过去，它一转就可能跳过 takeAll，因此先等 worker 把货收进本批。
- sendSettled：投递后按**序号**等「这次投递之后新挂的定时器」（旧的都已被 worker
放弃、再没人监听），供「投递与推钟交替」的用例（每 500ms 一条的绝对上限用例）。
- fireLatest/advanceAndFire 带 done 谓词重试，避免「登记与触发之间续臂」导致
推了钟却没人醒；waitIdle 一边等一边推窗口（worker 停在窗口里时永远走不到退休）。
- 用例侧只补相位与等待，不动断言：TwelveBurst 读历史前等 assistant 行落库；
准入用例断言「最新一次续臂」（原来按下标取 d[1]，隐含臂数假设）；
stale 用例两条都投完再推时钟（车道不会在两条之间退休）。
P2-1（替身锁无法用变异证实）选 A：删掉 stubChatter/stubSessions 的锁与访问器，
退回原字段访问，并写清理由 —— 21 个用例全走同步便捷路径
（b.process → processFrom → runBatch → Loop.Run），DEV HEAD 上 -race 数十次跑
（含把锁删掉的变异）DATA RACE 恒为 0；若将来从车道 worker 触碰这些字段必须加锁
并补 -race 用例。
证据：go test -race -count=3 ./internal/services/channelbridge/ 连跑 6 轮
18/18 全绿、DATA RACE=0；coalesce 子集 -count=80 全绿；整包 -race -count=20 全绿；
全树 go build/vet/test -count=1 全绿。
|
2026-10-24 23:18:45 +08:00 |
|