device-link:手机弱网/断连时发消息「排队且无法取消」,链路未就绪的可靠帧被静默丢弃、无失败反馈

**提交人**: 匿名
**客户端版本**: 0.0.0

---

## 现象(用户视角)

通过手机端(Cindy iOS 远程控制)控制桌面端时,在弱网 / device-link 链路断连情况下向会话发消息:

- 消息进入「排队」状态,但**无法取消**(排队项无法移除 / 撤销);
- 会话里始终不出现这条消息,也没有任何「发送失败 / 网络异常」提示;
- 回到桌面端后一切恢复正常。

## 使用场景

- 手机端经 device-link 远程控制桌面(「允许同账号设备控制本机」开启);
- 网络弱、或手机被系统后台挂起 / 锁屏导致 device-link 链路抖动;手机端因在后台不维持 WebSocket,本就不收 push,只能靠 invoke 主动发;链路断时 invoke 发不出去。

## 期望行为

1. 链路弱 / 断时发消息,应明确提示「发送失败 / 网络异常」,而不是无感知排队;
2. 失败的消息应保留为可重试(或可取消)状态,用户能主动放弃;
3. 链路恢复后自动补发未送达的消息(或至少明确告知「当前离线,已为你暂存」);
4. 排队中的消息应始终可取消。

## 附加技术线索(来自一次事故复盘,供定位参考)

事故会话中被控端日志观察到:

- 手机 peer 在故障时段反复断连:`reliable transport ACK timeout ... resetting peer link`,以及大量 `reliable transport buffer is full` 背压;
- **`dropping reliable payload before link is ready from `**(一次连续 9 帧)——被控端在链路未就绪时把手机端发来的可靠业务帧(invoke,含用户输入)**静默丢弃、不回 ACK、不落库**;
- 对应代码:`packages/device-link/src/client.ts`(约 1726–1736):`peer.linkReady` 为假时直接丢弃可靠帧,仅 `notifyReliableFrameBeforeLink` 节流通知 host,不向发送端返回失败;
- 事故会话历史里没有任何「无回应的手机端 user 消息」——与「手机端认为已发送 / 排队、被控端从未收到」一致;但用户 UI 显示「排队且无法取消」,两者关系需开发确认(可能手机端本地乐观入队,或消息确已入队后 drain 受阻)。

## 影响

远程控制是手机版核心场景,弱网是常态;当前行为导致用户消息**无感知丢失**,且排队项无法主动取消,体验和可靠性都受损。

## 建议排查方向

- 被控端 `client.ts` 链路未就绪时的静默丢弃路径:是否应向控制端返回明确错误(如 `LINK_NOT_READY`)供其展示失败反馈;
- 手机端发消息的 invoke 在链路断时的排队 / 取消语义;
- 链路恢复后的重放 / 补发策略(现有实现重连前会 `dropped N discardable pending frame(s)`,丢弃而非重放)。
---
**版本区域**: CN
**OS**: win32 x64 (10.0.26100)
**界面语言**: zh-CN

Start in packages/device-link/src/client.ts around lines 1726–1736 and trace the peer.linkReady false path, including notifyReliableFrameBeforeLink. Then inspect the mobile invoke queue and the reconnect log for discarded pending frames. Done means link failures produce actionable feedback, queued messages can be cancelled or retried, and recovery behavior is explicit without silently losing reliable frames.

Written by the indexing model from the issue text.