如果一个等待人工确认的流程已经被管理员停止，监控表却还显示它停留在等待步骤，不一定是停止操作没有生效。最后一条记录可能只描述了停止之前的情况；没有新的函数调用，负责写记录的插件就没有机会告诉报表发生了什么。

AWS在10月28日介绍Lambda durable functions遥测导出插件时，明确说明了这项边界：插件在函数内部运行，只能在函数被调用时输出；由服务端直接产生、没有新调用的STOPPED和TIMED_OUT状态，插件无法自行看到。要覆盖完整生命周期，需要结合相应状态事件更新记录。

先问这张表最近看见了什么

对接AI跟单或内部审批的长流程，运行可能跨多次调用，中间还会等待和恢复。某个步骤成功，不能证明整个工作完成；最后一条快照仍在等待，也不能证明当前仍有可恢复的任务。报表需要表达的是已有观察，而不是把旧观察自动延伸到现在。

因此，状态旁边应能找到最后观察时间及其来源。技术人员看到一条较早的等待记录时，需要查有没有后续服务端状态，而不是马上要求业务人员再批准一次。否则，监测缺口会变成新的人工动作，甚至引起对同一请求的重复处理。

这里也不能反过来把没有新记录当成已停止。长流程本来就可能长时间等待，缺少更新只说明当前监测没有取得更多信息。应区分已确认运行、已确认终止以及尚待核对，不用一个超时颜色替代真实状态。

停止和超时，要有自己的到达路径

AWS给出的补足方式，是接收默认EventBridge总线上的持久执行生命周期事件，并由处理程序更新目标记录。实际建设时，要确保事件对应同一个执行对象；按流程名称拼接可能混入不同买家或不同批次，不能只因为步骤名称一样就覆盖记录。

事件和快照还可能在不同时间到达。保存它们所描述的发生时间和身份，有助于避免较早快照后到却把终止状态改回等待。具体冲突处理需要按所用系统设计并测试，不应假设接入一个事件源就自动解决所有顺序问题。

业务通知也应使用核实后的状态。确认停止可以告诉负责人任务不再继续，但不等于外部操作已经撤销；某封邮件若在停止前发出，它不会因为运行被停就消失。应按已执行步骤核对影响，不把流程终止包装成全部业务回滚成功。

这与等待人工确认时暂停执行承担不同任务。持久等待保留后续恢复的执行条件，终态监测则告诉团队这个条件是否仍存在。界面上都像暂时没有动作，处理方式却不能混同。

测试时可以在受控环境准备不同结束方式：正常完成、步骤失败、人工停止以及执行超时。检查报表是否最终呈现相应状态，是否保留最后观察来源，通知是否指向正确执行。不能只演示一次正常完成，就宣布监测覆盖了整个生命周期。

对中国外贸团队，最先要避免的是让销售根据一张旧表做重复工作。若系统不能确认当前状态，给出待核对提示和负责入口，比自信显示“仍在等待”更有用。等真实终态补齐后，再决定跟进和恢复，不凭监测表上的旧一行重开业务。

参考来源