 AskaEth
|
f56d74c363
|
test(channelbridge): 准入三条用例改按「这条消息续出的臂」断言（M33 r2 复审 p2）
TestCoalesceSystemNoticeDoesNotJoinBatch 仍在用位置索引 d[1]：waitTimerCalls 只保证
「至少 2 次请求」，不保证顺序 —— 加压下会拿到 m1/m2 那次 2s 的续臂（实测 -race
-count=200 有 2/200 假红，空载测不出来）。
改成与兄弟用例同一口径，但把相位做成确定的：新增 sendSettledAndDuration ——
投递后等 worker 把这条收进本批、**为它**续好臂（按请求序号认领），再返回那次续臂的
时长。仅用 latestDuration 仍有缝：worker 可能在帧/通知之后才补上一条消息的续臂，
最新那次就成了 2s。三条准入用例（action 帧 / 系统通知 / 聊天消息对照组）统一改用它。
断言口径未变：仍然断言「系统通知/action 帧不重置静默窗口（剩余 500ms）」、
「聊天消息重置成完整 2s」；waitTimerCalls 语义、请求次数均未改。
证据：-race -count=400 连跑 3 次（1200 次）全绿、DATA RACE=0；
兄弟两条 -count=200 全绿；整包 -race -count=3 全绿。
|
2026-10-24 23:36:41 +08:00 |
|
|
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 |
|
|
AskaEth
|
ca8577f05b
|
feat(channelbridge): 群聊静默窗口合并与回合中续跑（M23）
主人 2026-10-23/24：「要让群聊聊天很自然，很流畅的做法」。群里「一鼓作气打三句」
此前会让她回三次；本片在**每会话车道头部**加一段静默等待，把这几句合成**一轮**回答
（批内每条仍是独立的一条消息，design/15 §2.1 不许拼成一条）。
四条不可走样：
- 🔴 主人私聊**结构性**无窗口：车道分 `newDirectLane`（无 batcher 字段、拿不到定时器
工厂）与 `newBatchLane`，类型由 actor 元数据（IsOwner() && !IsGroupChat()）决定，
配置无权翻转；
- 🔴 窗口内零丢失：唯一容器是车道队列（takeAll 单消费者取出），合并阶段无新增丢弃点
（CoalescedDroppedTotal 恒 0）；超单批上限的**尾部回插队首**保序、锁内、发车前；
- 🔴 一条批 = 一个 turnID = 一次 loop.Run = 一条助手回复；
- 🔴 不改「回什么」：闸门仍逐条跑（prepareInbound 逐字搬运 M22 的 processFrom），
被静默的消息进不了批。
实现落点：
- lane.go：direct/batch 两种车道 + front（回插队首）+ takeAll + 停机诚实登记；
- coalesce.go：生效参数解析、滑动窗口 + 绝对上限等待、发车原因与计数；
- coalesce_lane.go：攒批 → 拆分 → 陈旧度/闸门 → 发车；
- coalesce_prepare.go / coalesce_batch.go：processFrom 拆成 prepareInbound + runBatch；
- runtimeconfig/channels_coalesce.go：$DATA_DIR/config/coalesce.json（零新 .env 键）；
- gateway/admin_coalesce.go：GET/PUT /api/v1/admin/channels/coalesce（三态补丁 +
writeAuth + 审计 channels.coalesce + 热生效），routes.go 两行注册（塔已批）；
- 前端：渠道总览页一张卡（六个旋钮；主人私聊只给只读说明，不给开关）。
M22 既有用例仍在（lane_test.go 夹具显式关窗以钉住车道本身）；stranger_test.go 的那条
按塔裁定 #4 改写：「已有回合在跑 ⇒ 只登记不回」变成排队回答（留 WARN，绝不静默）。
回归：go build/vet/test ./... 全绿；三包 -race 全绿；前端 tsc --noEmit + npm run build
+ 渲染测试 36 项通过。不 push、不重启后端、未改 .env 与 Docs/。
|
2026-10-24 21:11:22 +08:00 |
|