部署在App Plan（B3）的Timer triggered Azure Durable function异常排查求助

云原生阿岚

2026-6-16

排查方向

检查App Service Plan的Always On设置
B3计划下必须开启Always On（在App Service的「配置」>「常规设置」里），否则App Plan空闲时会休眠，导致Activity函数无法被调度——Orchestrator因为Timer触发能启动，但后续调度Activity时进程已经休眠，自然不会执行。
查看Durable Task Hub的存储状态
找到函数绑定的存储账户，查看Tables里的DurableTaskHubInstances和DurableTaskHubWorkItems表，看看有没有未处理的Activity任务记录，或者是否有任务被标记为失败但没抛出异常。
深挖日志细节
别只看函数主页的运行记录，去Application Insights或者App Service的日志流里搜索Activity函数的名称，确认是否有调用痕迹，或者有没有被忽略的警告/错误——比如依赖缺失、权限问题，这些情况可能让Activity静默失败，Orchestrator那边没收到异常反馈。
核对Durable扩展版本
确保本地开发和部署到App Plan的Durable Functions扩展版本一致。不同版本在非消费计划下的调度逻辑有差异，旧版本可能需要额外配置。可以看host.json里的extensions.durableTask配置，或者门户里函数应用>「配置」>「应用设置」中的FUNCTIONS_EXTENSION_VERSION。
检查资源访问权限
确认Activity函数有访问所需资源（比如数据库、存储）的权限。消费计划下用的是系统托管身份，App Plan下可能身份配置不同，导致Activity执行时权限不足静默失败，没把错误传回Orchestrator。
复查Orchestrator代码逻辑
再核对Orchestrator里调用Activity的代码，确保函数名称没写错（大小写敏感），也没有条件分支导致Activity调用被跳过——比如某些判断逻辑下没执行CallActivityAsync，你可能没注意到。