Microsoft Durable Task Framework崩溃后无法从上次执行点恢复咨询

这不是框架的正常机制——Durable Task Framework的核心设计目标之一就是支持实例中断后的断点续跑，重启后从头执行说明你的实现或配置存在问题，以下是具体排查方向：

1. 编排器状态Checkpoint未正确生成 #

• 必须确保编排器通过await调用活动：框架会在await context.CallActivityAsync<...>的等待阶段自动保存状态 checkpoint，如果用同步调用（比如直接调用活动方法而非通过框架API）、或未正确使用异步模式，会导致状态无法持久化。
• 检查代码中第一个ApiCallActivity调用完成后，框架是否输出了状态保存相关的日志（比如"Checkpointing orchestrator state"）。

2. SQL持久化配置存在问题 #

• 确认重启前后应用使用完全相同的SQL连接字符串，如果指向不同数据库/实例，自然无法读取之前的状态。
• 查看SQL数据库中的DurableTask_Instances（或对应前缀的表）：检查第一次运行的实例是否存在，状态是否为Running/Suspended。如果实例记录不存在或状态为Completed，说明状态未被正确写入。

3. 未复用原有实例ID #

• 若每次启动都生成新的实例ID调用StartNewAsync，框架会创建全新的编排实例，而非恢复旧实例。测试断点续跑时，必须使用第一次运行时的同一个实例ID触发恢复。
• 核对两次运行日志中的实例ID字段，确认是否一致。

4. 代码变更导致状态反序列化失败 #

• 若重启前修改了编排器/活动的代码签名（比如方法名、输入输出类型、逻辑结构），框架可能无法反序列化已持久化的状态，进而重新执行实例。此时SQL表中可能会出现Failed状态的实例记录。
• 测试期间需保持编排器和活动的代码签名完全一致。

5. 框架或存储提供者版本问题 #

• 检查使用的Durable Task Framework版本是否存在SQL持久化相关的已知bug，建议升级到最新稳定版。
• 确认SQL存储提供者的配置正确，比如表前缀、锁超时时间等参数是否符合要求。

日志排查重点 #

对比两次运行日志，关注以下内容：

• 第一次运行时，第一个活动完成后是否有状态保存的日志条目；
• 重启后日志中是否加载了原有实例ID，还是生成了新ID；
• SQL数据库的操作日志中，是否有写入/读取实例状态的记录。

内容的提问来源于stack exchange，提问作者Akbar Badhusha