memrelay
b73900b969
MemRelay-Operation: checkpoint-save:issue3-rootcause-diag-20260930-1235 MemRelay-Resource: 7fd55d99-e2fa-4f59-b963-2b14d5e592b7
3.0 KiB
3.0 KiB
title, type, permalink, stable_id, scope, memory_type, project_id, usage_profile_id, status, revision, request_id, created_at, updated_at, tags
| title | type | permalink | stable_id | scope | memory_type | project_id | usage_profile_id | status | revision | request_id | created_at | updated_at | tags | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Checkpoint 2026-09-30 04:37:44 UTC [cea96f7c13] | checkpoint | main/projects/25464650-ed5d-440e-b362-190f2852d451/checkpoint-2026-09-30-04-37-44-utc-cea96f7c13 | 7fd55d99-e2fa-4f59-b963-2b14d5e592b7 | project | checkpoint | 25464650-ed5d-440e-b362-190f2852d451 | 0c9feb46-d06e-43cd-9ef0-c5813c84a998 | active | 1 | issue3-rootcause-diag-20260930-1235 | 2026-09-30T04:37:44.082486+00:00 | 2026-09-30T04:37:44.082486+00:00 |
|
检查点：issue #3 根因已实证（不是服务端死锁）
基线 main 4059a15。诊断工作树 E:\code\NixMsg-wt\diag3（分支 diag/issue3-scratch，仅本地，完成后删除）。
结论
TestUplinkDMOfflineGroupRecall 等"resp 回不来"是测试用 WebSocket 客户端 test/harness/mqtt.go 的两个缺陷，不是服务端死锁：
- wsMQTT.Recv 把一个 WS 二进制帧当作恰好一个 MQTT 包；mochi 在 outbound 有积压时把多个包放进 outbuf 一次 Write，合成一个 WS 帧（MQTT5 §6 [MQTT-6.0.0-3] 允许）。客户端只解第一个包。实证日志：
WS frame carries 3 MQTT packets: [group_event group_event resp/rid=g1]随后timeout waiting resp rid=g1。通过的轮次里也在丢 receipt/group_event。 - wsMQTT.Send / writeWSClientFrame 帧头和载荷分两次 Write、无锁；读循环回 PUBACK 与测试线程发请求并发时交错，把发往服务端的 WS 流写乱，服务端卡在读一个错乱长度的包（无报错日志）。
对照实验（同步 emit，无 20ms sleep）
- 原客户端：6 次 1 失败（合帧含 resp）。
- 只修接收按字节流拆包：20 次 2 失败（g1、s4，无服务端报错）。
- 再修发送加锁+整帧一次写：20/20 通过（125 个合包帧正确拆开）；cmd/nixmsg、test/accept、group、broker 全绿。
解决方向
- 修 test/harness/mqtt.go：Recv 按字节流缓冲拆包（含 continuation 帧）；Send/PONG 加互斥锁并整帧一次 Write。
- 修好后删除 internal/app/group/app.go emit 的 goroutine+20ms sleep，改回同步下发。
- 不要合入 E:\code\NixMsg-wt\fix3 的 broker 改动（基于错误假设，改变 PUBACK 时序）。
- 更正 docs/DEVIATIONS.md 「死锁未修（issue #3）」与 Q accept-rest 第 3/4 条的错误结论。
另发现的真实隐患（待入 issue）
- mochi v2.7.9（最新版）inflight.go NextImmediate 先 RLock 再调 GetAll 又 RLock，递归读锁；server.go processPacket 719-728 在 sendQuota>0 且 inflight 非空时调用。客户端带 ReceiveMaximum（SDK 可能带）时，与 publishToClient 的 Inflight.Set 写锁排队可永久互等，卡死该连接读循环及所有向其下发的 goroutine（含 messageLoops）。测试客户端不带 ReceiveMaximum 所以没触发。
- identity lifecycle.go 有 kickFlushDelay=20ms sleep（fix #4 引入），待审。
下一步
全量审查 + 写 issue（含不冲突的解决方案与并行分组），交负责人审核后由 Grok 团队修。