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
..
2026-10-04 19:55:18 +08:00
2026-09-06 04:26:02 +08:00
2026-10-24 20:32:36 +08:00
2026-10-24 20:17:17 +08:00
2026-10-24 21:11:22 +08:00
2026-10-04 10:54:07 +08:00
2026-10-06 15:59:16 +08:00
2026-09-08 21:36:03 +08:00
2026-10-05 13:11:04 +08:00
2026-10-03 15:22:03 +08:00
2026-10-04 12:49:40 +08:00
2026-09-06 04:17:20 +08:00
2026-10-24 22:24:14 +08:00
2026-10-24 23:18:45 +08:00
2026-10-06 18:46:27 +08:00
2026-10-04 12:07:51 +08:00
2026-10-24 19:42:58 +08:00
2026-09-05 23:09:26 +08:00