 AskaEth
|
28afa11aeb
|
feat(channelbridge): 出站语音结论落 voice 列并挂出站 Media（M58）
- voice.Ref 增 SourceTTS 与 FallbackReason，Validate/IsZero/validSource 同步
- 出站成功：INSERT -> 补写 voice 列 -> notify（首帧即带 voice）
- 出站降级：source=tts + status=failed + fallbackReason，正文原样
- 首条气泡挂出站 Media（新开条目，不复制 target.Media）
- gateway historyVoice 投影 fallbackReason
- 新增 outbound_voice.go 与整链 e2e 测试（含变异打红验证时序）
|
2026-10-27 22:08:38 +08:00 |
|
|
AskaEth
|
b955a27479
|
fix(channelbridge): M44 入站语音先写 voice 列再广播 ⇒ 首帧就带 voice
安卓 2026-10-26 回执关心的场景：新来一条语音消息时，**第一条**帧里有没有
`voice`。此前没有 —— `persistBatchUsers` 先 `persistToMain`/`persistIsolated`
（内部同步 notify 把帧发出去），之后才 `persistMessageVoice` 写列，帧发出那
一刻列还是空串。网关侧的帧投影（上一 commit）读的就是这一列，因此首帧必然
缺 voice，客户端要等重连或下一次 REST 拉取。
修法（A 路的唯一可行形态，理由见下）：
- `persistBatchUsers` 的通知改成 `persistVoiceFirstNotify(ref)`：
**INSERT → 写 voice 列 → notify**。语句数不变，只把 notify 从 INSERT 内部
挪到最后；非语音消息（ref 零值）时该包装与 `notifyPersisted` 逐字等价。
- `persist.go` 抽出 `mainRow` / `isolatedRow`（字段清单只写一次）与
`persistIsolatedWith`（可注入通知的变体），`persistToMain`/
`persistIsolated` 的对外行为逐字不变。
为什么不走 B（给 `history.Message` 加 voice 随 INSERT 写）：`persistMessageVoice`
是按 id 的 UPDATE，行还不存在时必然 `ErrMessageNotFound` ⇒ 写列**不可能**真正
挪到 INSERT 之前；可行的最小形态就是上面那次换序，无需动 domain 类型、列清单
与 7 条读语句。B 若要做，属于 design/24 §10.5 的独立切片（那时还应删掉这里的
两段式，避免同一事实两处写）。
整链验收（`inbound_voice_gateway_e2e_test.go`，真桥接器 + 真存储 + 真网关 WS）：
- 主人私聊语音：第一帧就是 `message_persisted`，带 `voice`，且与
`GET /sessions/{id}/messages` 同一行**逐字相等**；随后的非语音消息帧整键缺席。
- 群聊语音（被点名 ⇒ 走完整回合）：第一帧 `channel_persisted` 带 `voice`，
且与渠道日志读面同一行逐字相等。
- 变异实测（把顺序还原成「先广播、后写列」）：两条用例都 FAIL，输出即报障症状
（帧里 content 是转写文本，却没有 voice 键）。
顺带把网关侧两处描述旧时序的注释改成新事实。
|
2026-10-26 18:54:13 +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 |
|