Azure Durable Functions混合部署槽调用异常原因排查

假设代码本身无逻辑错误，以下是几种常见的跨槽调用触发场景：

• 应用配置参数错误
  如果F1调用F2/F3时依赖应用设置中存储的函数端点（比如F2的HTTP触发URL），而生产槽(S1)的对应配置项误填为测试槽(S2)的端点地址，会直接引发跨槽调用。另外，若使用Durable Functions内部调用，WEBSITE_HOSTNAME等槽标识类配置项设置错误，也会导致路由指向错误的槽。

• 部署槽交换后的残留问题
  若近期执行过槽交换操作（比如将S2交换至S1），可能出现配置同步不彻底或Azure路由缓存未及时更新的情况。比如交换后，函数内部调用的路由规则仍残留旧的槽地址，导致S1的F1调用S2的函数。

• Durable Functions实例状态异常
  因为F1是编排器函数，如果该实例最初在S2槽中创建，后续通过槽交换迁移到S1，但Durable Task Framework存储的实例元数据仍指向S2的F2/F3端点，就会引发跨槽调用。此外，存储账户中残留的旧实例状态数据，也可能让S1的F1读取到错误的端点信息。

• 路由或域名配置错误
  若函数应用配置了自定义域名，而DNS解析错误指向了S2槽，或者流量管理器/应用网关错误地将生产流量路由到S2，当F1使用自定义域名调用F2/F3时，就会访问到测试槽的函数。另外，自定义路由规则（routes.json）配置错误也可能导致这类问题。

• 发布或调试残留配置
  发布S1槽时，如果不小心将本地调试环境中指向S2的端点配置打包进了生产槽，或者发布过程中没有正确替换槽专属的配置参数，就会导致S1的函数实际使用S2的端点地址。

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