诊断与事件投影

English | 简体中文 | 首页

用下面的接口检查当前部署、消费事件，也可以排查任务为什么未执行以及取消后的状态：

能力	入口
实际导入的包、源码与存储兼容性	dispatcher_sdk.runtime_identity(...)
先持久化、后 ACK 的事件消费	ProjectionConsumer(...).drain(...)
Run 当前无可领取工作的原因	sdk.inspect_work_availability(run_id)
取消阶段、清理状态和恢复身份	sdk.inspect_cancellation(run_id)
托管任务已保存的活动和事件分页	task.observe() 与 task.events()

投影回调必须先提交幂等写入事务，再返回 persisted 或 already_present。 回调使用由 source_id、run_id 和 sequence 组成的稳定事件身份去重，并在同一事务中 提交去重记录和业务写入。persisted 表示本次已经写入；already_present 表示这个事件 已在此前的事务中处理并持久化。整页事件都确认后，消费者才会 ACK 这一页。 没有完成 ACK 的页会重放，处理失败的事件会阻塞该页，不能跳过。 drain 的目标高水位（本轮要处理到的事件位置）是固定的，但 Run 持续并发更新时，ACK 仍可能因版本冲突而失败。

诊断查询不会同步或修改 Run。字段缺少证据时保留 unknown（未知，不代表零或否定）；跨库读取也受快照一致性限制。 工作诊断有 Effect 扫描上限；超过上限时计数为未知，不是零。

执行观测也只读已记录的事实，不会领取任务、续租或清理进程。时限、子任务和可选停滞通知的 说明见执行观测与监督。

为 Runtime 显式配置 cancellation_journal_path 和 source_id，可以持久保存取消证据（之后用来核对取消结果的记录）。 回执存放在独立的 schema 1（数据结构版本 1）数据库中，核心存储不会自动迁移。 只有同一执行代际（相同的 attempt/fence）留下的 Linux subreaper 或 Windows Job 清理记录， 才能证明本地进程树已经清理。 即使没有配置这个可选的取消 journal，inspect_cancellation 也可以从与 Kernel 存储绑定的 settlement journal 只读读取匹配的 process_cleanup note。Runtime 重启后、没有活动 Runtime 时也能读取。只有 Kernel 绑定、execution ID、attempt 和 fence 都匹配，且 note 为 confirmed、来源为 runtime_supervisor_reaped，才会确认清理；note ID 和来源会与取消回执 ID 分开显示。缺失、格式错误或来自其他执行身份的 note 仍为 unknown。本地进程清理已确认， 也不会结清仍待处理的沙箱销毁义务。 取消 Task 不会自动结束 Run。

完整说明见 API 指南、回执存储设计、投影示例和诊断示例。