维护者确认: fix(device-link): push 拥塞入队改 latest-wins 腾位,消除 BACKPRESSURE 风暴

[MagicLizi]

触发

• 类别: arch
• 原因: core-paths(核心路径改动 465 行 ≥ 150)
• 作者: painfulChen

当前状态

• 2 个 workflow 待批准才能跑 CI
• 维护者 dashhuang 已在评论区给出详细 review,认可 latest-wins 方向,将直接在分支上补 commit 收尾

确认方式

维护者请在 PR 上直接 Approve;需要修改请提 Request Changes,作者改完后重新 Approve 即放行。

---

关联 PR:#2167(作者 @painfulChen);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的技术架构调整,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断

这项改动值得推进，但应明确定位为：在本地可靠发送队列饱和时，为 maker:event 镜像流量提供受限的 latest-wins 入队止损。它可以减少重复 BACKPRESSURE、提高弱网恢复后的新鲜状态交付率，但不改变出站速率，也不处理 relay 的聚合背压，因此不能据此认定 device-link 拥塞已经整体根治。

当前 main 快照 cba45371cb1869c6bbe9b47e35fb17c12e94363b 中，这个缺口仍然存在：packages/device-link/src/client.ts 的 sendPeerEnvelope 在 pending 满时，只会为 invoke-result 清理队首可丢弃前缀；普通 push 仅在超龄 TTL 清扫后重试容量判断，新 push 对新鲜 push 仍会抛出 BACKPRESSURE。因此 #2167 不是已合入修复的重复报告。

进一步检查发现，“所有 push 都是可丢弃状态镜像”并不成立。apps/desktop/src/main/contacts-sync/sender.ts 按顺序发送加密分片，并将 BACKPRESSURE 明确作为流控信号：每 50ms 重试，最长等待 30 秒。若传输层允许任意新 push 静默驱逐已经入队的 contacts-sync 分片，发送端会误以为该分片已成功，接收端则可能永远无法完成组装。

#2167 当前 head 已根据维护者 review 收窄：只有显式白名单中的镜像通道可以发起并承受驱逐，非镜像 push 保留原背压语义；同时把 WebSocket 容量检查移到驱逐之前，避免 socket 本身已满时“旧帧被删、新帧也未入队”。这些是合并所必需的安全边界，当前方向可以接受。

行动

1. 先批准并执行当前等待中的两个 workflow。
2. CI 全绿后，由维护者在 fix(device-link): push 拥塞入队改 latest-wins 腾位，消除 BACKPRESSURE 风暴 #2167 上完成架构 Approve；不建议仅凭本讨论 Issue 直接放行未经 CI 验证的 head。
3. 合并前确认以下行为由最新代码和回归测试锁定：
   • 只有显式白名单中的镜像通道能够触发 latest-wins；
   • 只能驱逐队首连续的同类可丢弃帧或 transport-skip，占用序列通过 baseSeq 前移整体跳过，不制造中间 seq 空洞；
   • contacts-sync 等非镜像、有序或依赖 BACKPRESSURE 流控的 push 不能发起驱逐，也不能被镜像洪峰驱逐；
   • 队首是 live invoke / invoke-result 时停止驱逐并维持原 BACKPRESSURE；
   • WebSocket native buffer 容量不足时，在修改 pending 之前失败，现有待重放历史保持不变；
   • 消息数和字节数两种 pending 上限、TTL 单调时钟清扫、迟到 ACK 与 peer 隔离均不回归。
4. 自动测试通过后，建议补一次可控弱网双端验证，至少记录：
   • reliable transport buffer is full 的次数是否从持续风暴降为边界场景；
   • ACK 恢复后控制端是否收到较新的 maker:event，并能通过既有重新订阅/全量同步最终收敛；
   • 一次经 relay 回退的 contacts-sync 多分片传输是否完整完成；
   • relay 1013 inbound backpressure 是否仍可能出现。该指标用于确认范围，而不是要求本 PR 必须改善。

关键技术依据

当前 main 的行为

• packages/device-link/src/transport.ts 将单 peer 未确认消息限制为 64 条，并同时设置 16 MiB pending 字节上限和 8 MiB WebSocket bufferedAmount 上限。
• packages/device-link/src/client.ts 已有安全的队首前缀驱逐与 baseSeq 前移机制，但当前仅服务于建链重放清理、invoke-result 腾位和超龄 push 清扫；普通新鲜 push 之间仍相互背压。
• 这说明 fix(device-link): push 拥塞入队改 latest-wins 腾位，消除 BACKPRESSURE 风暴 #2167 复用的是已有可靠流恢复机制，不需要新增 wire kind 或字段；真正新增的是拥塞时哪些业务帧允许被牺牲的策略。

为什么必须按通道限制

apps/desktop/src/main/contacts-sync/sender.ts 的 sendRelayFrame 循环只有在调用成功后才推进下一分片，并对 BACKPRESSURE 做有界重试。这是明确存在的“push 作为有序数据流”入口。因而缺少白名单会改变已上线功能的正确性，不只是理论风险。

另一方面，历史实现已经证明 latest-wins 适合经过语义确认的状态镜像，但不能从某一个镜像通道推广到全部 push。#1401 对 sessions:activity 使用按 (controller, sessionId) 键控的 latest-wins，同时明确保留 maker:event 等事件流逐帧发送。#2167 现在是一次更具体的产品取舍变化：维护者根据新的生产数据接受 maker:event 在可靠队列饱和时作为可恢复镜像处理。因此应以显式白名单和恢复验证固化这一新边界，而不是把“push”本身当作可丢弃语义。

范围与风险

该改动只改变本地 pending 满时的取舍，不减少生成或写入 WebSocket 的帧速率。维护者在 #2167 的 review 中记录的 1013 inbound backpressure 属于 relay 聚合背压，仍需后续的发送端微批、pacing 或其它速率层工作处理。建议 PR 标题、描述和发布说明避免使用没有范围限定的“消除拥塞/BACKPRESSURE 风暴”。更准确的表述是“减少 maker:event 本地 pending 饱和造成的 BACKPRESSURE 重试风暴”。

相关记录

• fix(device-link): prevent stale pushes from starving invoke-results in reliable transport buffer #1375：已合并的传输层基础。它为 invoke-result 驱逐队首可丢弃前缀，并验证通过 baseSeq 大步前移安全跳过连续 seq；fix(device-link): push 拥塞入队改 latest-wins 腾位，消除 BACKPRESSURE 风暴 #2167 复用同一协议不变量，把准入扩展到受限镜像 push。
• fix(device-link): 会话活动推送 latest-wins 整流 + replay 定向补发,根治订阅风暴拥塞 #1401：已合并的源头整流先例。它只对确认具有状态镜像语义的 sessions:activity 做键控 latest-wins，并保留其它事件流逐帧发送，直接支持“按语义白名单、不能按 envelope kind 一刀切”的判断。
• feat(contacts): 支持桌面设备间安全同步 #1214：已合并的 contacts-sync 功能引入了经 Device Link relay 顺序发送的加密分片；其发送端依赖 BACKPRESSURE 重试，是 fix(device-link): push 拥塞入队改 latest-wins 腾位，消除 BACKPRESSURE 风暴 #2167 必须保护非镜像 push 的直接原因。

[MagicLizi]

关联 PR #2167 已合并(https://github.com/makecindy/cindy/pull/2167),这次产品讨论的结论已随 PR 落地,自动关闭本 issue。后续还有想继续聊的,直接 reopen 或另开 issue 都行。