Files
go-sip/docs/evidence/task5-control-original-20261009.md
T

41 lines
4.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 新空任务控制消息原文核验(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。