docs: prove missing issued_at in live task5 control

2026-10-09 21:32:40 +08:00
parent 41e0d0c3dd
commit 416f3c9f05
1 changed files with 40 additions and 0 deletions
@@ -0,0 +1,40 @@
+# 新空任务控制消息原文核验（2026-10-09）
+
+## 授权与范围
+
+使用者确认：新建并开启独立空任务，临时停止 Dispatcher 后先保存原消息，再校验保存内容及实际处理；不导入号码、不拨号、不操作任务 3/4、不清队列、不发送人工反馈。原消息只存私有文件，不写普通日志或提交。
+
+代码基线 `41e0d0c3dd56747daf4f51508faedaba390f8041`；共享合同 `ff74afe396eb811745a20cd88d167585d6593132`，已同步并通过合同核验。本轮不修改 Schema、运行实现、源消息或反馈状态。
+
+## 实际创建与保存
+
+原生 Asterisk 核对零活动通道/通话后停止 Dispatcher。通过真实租户页面创建任务 **5**：名称“队列原文核验-20261009”、租户 1005、任务并发 1、线路并发 1、号码 0；选用已存在模型和已启用线路，不改变模型或线路配置。创建请求返回 200，正常任务列表确认唯一新记录。
+
+页面开启确认发出 `POST /prod-api/call/task/start/5`，返回 200。SaaS 实际发布的动作是 **resume**，不是 start；该动作在现行合同内合法，不能因页面名为“开启”而认定动作错误。
+
+专用诊断仅被动读取登记 Dispatcher 的控制队列与任务 5 队列，检查无活动消费者。控制队列 1 条消息，任务队列 0 条；控制消息 222 字节，JSON ContentType、persistent。保存完整 AMQP 元数据和原始 body 后 fsync，再从文件读回，原 body SHA-256 完全一致。未 ACK、未建/删/绑定/purge 队列；关闭诊断通道将未确认原消息返回原队列。
+
+私有证据目录：测试机 `~/.local/share/go-sip/evidence/20261009T132311Z-task5-original/`，0700；文件 0600。包括 UI 创建/开启请求响应、任务身份、原 AMQP 消息、队列核验日志、完整校验报告、实际处理日志和最终主机状态。本机副本在忽略目录 `.local/diagnostics/new-task-capture/`。
+
+原 body SHA-256：`d8a335d4c41d86fa9f4c9aef989680572e610450e97cdcfed5c09db1e72123b1`。
+
+## 已确认根因
+
+现行 `contracts/schema/mq-task-control-request.schema.json` 要求根字段 `issued_at`。保存的真实控制请求包含事件/Dispatcher/租户身份和任务 5 的 resume/action/reason，但**缺少 issued_at**。
+
+- 项目现行 MQ 验证器明确拒绝原消息。
+- 使用已有 JSON Schema 工具、固定共享合同、全部引用资源和格式检查，对完整请求校验：唯一错误是缺少 `issued_at`。
+- 仅在内存副本中添加符合 Schema 的时间字符串，其余字段不变，完整校验通过。
+- 该内存副本只用于定位，**没有发往队列或覆写保存原文**；不伪造原生成时间。
+
+因此，消息在正常任务处理/反馈生成之前被拒绝，页面保持“开启中”。本次证明的直接阻断是**入站控制消息缺少必填时间字段**，不是反馈队列传输失败，也不依赖猜测反馈 `rejected/applied` 的外部含义。应由 SaaS 控制消息生产方补上真实命令生成时间；若要改变字段约定，须另行确认并同步共享合同，不能在 Dispatcher 静默补默认时间。
+
+## 处理复现与附带发现
+
+恢复原 Dispatcher 后，原消息被重新投递；日志证实 `invalid control queue message; admission stays closed` 及启动 drain 的 `mq validation failed at /`。服务因这条无效消息失败关闭并重启一次，普通日志没有指出具体字段；仅看根路径无法诊断，本次靠事先保存原文才确认根因。
+
+当前拒收路径不保留生产原消息，也没有正常控制 outbox；未来若未经留证便重发，仍可能再次失去排查依据。此为尚未修复的可观测性/原消息保留问题，不以本轮一次性诊断工具代替正式修复。
+
+重启后的 HTTP 发现把任务 5 持久状态记为 running，但 inbox/outbox 仍为 0，**不能把该 HTTP 状态当作控制消息处理成功或反馈送达**。页面重新核对仍显示“开启中”，0/0。
+
+结束核对：Dispatcher/Agent/Asterisk active+running，Dispatcher NRestarts=1，discovery_ready=1，内部 SIP 26/pending 0；原生零活动通道/通话。没有实际呼叫、AI/OSS 请求、人工反馈、原消息改写、重置业务数据或重启 Asterisk。