DSH 定时推送没收到：按投递链路排查

早上没收到天气推送，多数不是模型没生成，而是任务没触发或生成后没送达。DSH 里 schedule 只负责把提示词送进会话，模型产出后再由投递环节发到渠道，两段独立，需分开查。

一、先分清“没触发”还是“没送达”

会话记录在 /sessions/ 下的 session.v4.jsonl.zstd。解压后翻到设定时刻附近，看有没有 schedule 触发的用户消息：有则问题在后半段，没有则查 schedule 本身。

DSH 重启后会补发最近一次错过的任务，所以关机或重启期间的消息可能延迟出现，会话记录里时间戳会明显晚于设定时刻。

二、检查投递目标是否存在

投递目标写在 /integrations/dsh-<渠道>/workspaces.json 的 deliveryTargets 里，目录名随渠道变化，例如 dsh-im。确认存在与任务目标会话或群组对应的条目。常见故障：条目被删或改名，任务仍指向旧标识；或配置了多个目标，任务只绑定了其中一个，消息发到了别处。

改完需让 DSH 重新加载配置，方式以当前版本为准，并用下一节验证是否生效。

三、直接调用本地投递接口验证链路

绕开 schedule 手动发一条，判断投递是否通畅。接口只监听本机回环，无需鉴权：

curl -s -X POST http://127.0.0.1:3080/api/dsh-im/delivery/messages \
  -H 'Content-Type: application/json' \
  -d '{
    "botId": "weather-bot",
    "targetId": "daily-weather",
    "text": "投递链路测试",
    "format": "plain"
  }'

四个字段都要给全。botId 是发送方标识，targetId 对应 deliveryTargets 里的目标标识，format 只接受 plain 或 markdown，其他值会被拒绝。返回 {"sent": true} 表示受理，再去目标会话确认。

返回成功但会话无消息，回到第二节核对 targetId 与 deliveryTargets 的键是否完全一致，包括大小写。接口直接报错时看错误信息里的字段名，多半是 botId 或 targetId 不存在。

四、确认 schedule 的绑定关系

手动投递成功说明接口和目标没问题，剩下查任务绑定。会话被重建、渠道重新授权后标识可能变化，旧任务仍指向旧值，表现是“任务在跑，消息进了空处”。补发时若目标已失效同样会失败，且没有明显提示，所以以会话记录的触发时间和接口返回为准，别只看任务存在。

五、怎么判断卡在哪一步

看三个信号：会话记录里有没有当天的 schedule 触发消息；手动调用是否返回 {"sent": true}；目标会话里是否出现测试消息。无触发查 schedule，有触发无送达查 deliveryTargets，接口成功但无消息查 targetId 匹配。

六、边界

这套排查只覆盖 DSH 内部的触发与投递。渠道侧频率限制、机器人被移出群组、渠道服务异常时，DSH 可能仍返回受理成功，消息却在渠道侧被丢弃，需到渠道侧查。手动调用会真实发送消息，测试时别发到对外群组。修改 workspaces.json 前先备份，格式错误会导致整个渠道集成加载失败。