From 7b209ce3d6a4a4852b29059fd800383e77ff6a45 Mon Sep 17 00:00:00 2001
From: Nixevol <guaotiantang@outlook.com>
Date: Wed, 30 Sep 2026 12:11:07 +0800
Subject: [PATCH] =?UTF-8?q?docs:=20=E8=AE=B0=E5=BD=95=20issue=20#3=20?=
 =?UTF-8?q?=E4=B8=8B=E8=A1=8C=E6=AD=BB=E9=94=81=E6=9C=AA=E4=BF=AE?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/DEVIATIONS.md | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/docs/DEVIATIONS.md b/docs/DEVIATIONS.md
index 344f000..ac2fa7e 100644
--- a/docs/DEVIATIONS.md
+++ b/docs/DEVIATIONS.md
@@ -1137,3 +1137,37 @@
    - 原因：空指标等于监控未交付；采样避免在每条写路径上改大段分发逻辑，并减小与 #3/#6 的合并面。  
    - 备选方案：全部改为纯事件加减（pending 等需在每处状态迁移维护计数）。  
    - 影响：仪表盘按既有名字即可看在线连接与待投递；无对应事件时计数保持 0，不做假数。
+
+### 死锁未修（issue #3）
+
+issue #3 未关闭，`feat/fix-3-downlink-deadlock` 未合入 `main`。下面是核对过的调用链、三次尝试和仍留在 `main` 上的绕过。不改产品行为。
+
+1. **现象**  
+   - 清掉测试客户端 dial deadline 后，`cmd/nixmsg/uplink_integration_test.go` 的 `TestUplinkDMOfflineGroupRecall` 在 `group.create`（`rid=g1`）稳定超时，`resp` 回不去。  
+   - 行号以本次合入后的 `main` 为准。
+
+2. **调用链**  
+   - 每端一条上行队列。`internal/broker/queue.go` 的 `loop`（约 41 行）同步调用 `HandleUplink`。  
+   - `cmd/nixmsg/uplink.go` 的 `HandleUplink`（约 64 行）先 `dispatch`，再在同一调用栈里 `replyOK` → `publishResp`（约 273 行）用 QoS 1 调 `PublishDown`。`group.create` / `group.add` 走 `groups.Create` / `Add`，在返回 `resp` 之前就 `emit`（`internal/app/group/app.go` 约 168、223 行）。  
+   - `Broker.PublishDown`（`internal/broker/broker.go` 约 202 行）进入 `server.Publish`（约 234 行）。`New` 设了 `InlineClient: true`（约 148 行，DEVELOPMENT 要求保持）。Inline 发布走到 `InjectPacket` → `OnPublish`。  
+   - `internal/broker/hooks.go` 的 `OnPublish`（约 114 行）对 `cl.Net.Inline` 必须直接放行，否则 `PublishDown` 送不到订阅者（见本文更早的 InlineClient 偏差）。  
+   - 群操作因此在同一次上行调用栈里，再向本连接 `PublishDown` `group_event`。`InjectPacket`（`NextPacketID` / 写路径）与读循环随后写 PUBACK 抢同一把 Client 锁，两边互等，`resp` 出不去。  
+   - `presence.notify`（`internal/app/presence/app.go` 约 317 行）仍在业务调用栈里同步 `PublishDown`（约 341 行），不在 20ms 绕过的覆盖范围内。
+
+3. **已尝试**  
+   - 尝试 1：`emit` 改成立刻起 goroutine 做 `PublishDown`。仍死锁，因为 `group_event` 与同连接上的 `resp` 一起抢注入。  
+   - 尝试 2（已在 `main`，来自 `479a08e` 的 Q accept-rest 第 4 条）：`emit` 起 goroutine 后 `time.Sleep(20ms)` 再下发（`internal/app/group/app.go` 约 672–685 行），让 `resp` 先出去。当时 `task check` 通过。这是时间差绕过，不是根因修复；presence 以及其他同步 `PublishDown` 仍可能卡。  
+   - 尝试 3（负责人叫停，未合入、未验证）：工作树 `e:\code\NixMsg-wt\fix3`，分支 `feat/fix-3-downlink-deadlock` 停在 `479a08e`，与合入前的 `origin/main` 相同，**没有可合的提交**。未提交改动在 broker 层：  
+     - `hooks.go` `OnPublish`：客户端 QoS≥1 先在读循环里 `WritePacket(PUBACK)`，再把包降成 QoS 0 并 `Ignore`，然后入队，返回 `nil`（不再用 `CodeSuccessIgnore` 让 mochi 事后写 PUBACK）。注释写明：若先入队，worker 的 `PublishDown` → `InjectPacket` → `NextPacketID` 会与随后的 `WritePacket(PUBACK)` 争 Client 锁。  
+     - `queue.go` `loop`：`HandleUplink` 前后调用 `beginUplink` / `endUplink`。  
+     - `broker.go`：该端 `depth>0` 时，对本端的 `PublishDown` 只推进延后队列，handler 返回后由上行 worker 再 `server.Publish`；其他端仍同步下发。`InlineClient` 放行未改。  
+     - `group/app.go` `emit` 改回同步 `PublishDown`，去掉 20ms sleep。  
+     - 同目录 `docs/DEVIATIONS.md` 有一段未提交的 `### fix-issue-3` 草稿。  
+   - 本会话没有跑这套未提交代码的 `task check`，不把它们合进 `main`。工作树保留，给工程师看。
+
+4. **仍在 main 上的做法**  
+   - 继续用尝试 2 的 20ms 绕过。群事件可能略晚于 `resp`；业务结果仍以 `resp` 为准。
+
+5. **建议的正确方向**  
+   - 在 broker 把对本连接的下行 `InjectPacket` 与上行 worker 解耦：上行读循环先写完 PUBACK，处理 `HandleUplink` 期间不要同步向本连接注入；handler 返回后再发 `resp` 和 `group_event`。不要靠固定 `Sleep`。`InlineClient: true` 保持，`OnPublish` 对 InlineClient 继续放行。  
+   - 覆盖 presence 等其他同步 `PublishDown`，而不只包一层 `emit`。