Azure Durable Functions Python SDK：Service Bus触发的客户端函数启动编排函数时遭遇500内部服务器错误

让我们一步步拆解你的代码问题，帮你搞定这个500错误：

核心问题分析 #

从你的代码来看，主要有几个关键问题导致启动编排失败：

1. 缺少logging模块导入 #

你的代码里调用了logging.info()但没有导入logging模块，这会直接触发NameError，是导致500错误的一个直接原因。

2. 编排函数名称获取错误 #

你用msg.route_params["Orchestrator"]来获取编排函数名称，但route_params是Service Bus主题订阅的路由参数，只有当你在Service Bus主题中配置了对应路由规则时才会有这个值。如果你的编排函数是固定名称（比如叫MyOrchestrator），应该直接传入函数的名称字符串。

3. 异常处理不够完善 #

当前的异常处理只记录了错误信息，但没有明确的错误反馈，不利于排查问题，甚至可能掩盖真实错误。

修正后的代码 #

下面是修复后的完整代码，我标注了关键修改点：

import json
import logging  # 新增：导入logging模块，解决NameError问题
import azure.functions as func
import azure.durable_functions as df

async def main(msg: func.ServiceBusMessage, starter: str):
    try:
        # 简化消息解析逻辑，避免多余的嵌套结构
        msg_body = json.loads(msg.get_body().decode('utf-8'))
        account_name = msg_body.get('accountName')
        
        # 初始化Durable编排客户端
        client = df.DurableOrchestrationClient(starter)
        
        # 修改：直接传入编排函数的实际名称，替换成你自己的编排函数名（比如"MyOrchestrator"）
        orchestrator_name = "YourActualOrchestratorFunctionName"
        # 如果需要给编排函数传参，第三个参数可以传入msg_body，让编排函数获取消息内容
        instance_id = await client.start_new(orchestrator_name, None, msg_body)
        
        logging.info(f"Started orchestration with ID = '{instance_id}', target account: {account_name}")
    except Exception as e:
        # 优化：记录完整错误堆栈，便于排查深层问题
        logging.error(f"Failed to start orchestration: {str(e)}", exc_info=True)
        # 重新抛出异常，让Azure Functions捕获并返回正确的错误状态，避免静默失败
        raise

额外注意事项 #

• 确保orchestrator_name的值和你编排函数的实际名称完全一致（区分大小写），比如你的编排函数装饰器是@df.orchestration_trigger(context_name="context")，函数名为my_orchestrator，这里就填"my_orchestrator"。
• 如果不需要给编排函数传参，start_new的第三个参数可以保留None，但建议传递消息体，方便编排函数后续使用业务数据。
• 排查时可以查看Azure Functions的详细日志：进入函数的“监控”->“日志”页面，搜索Failed to start orchestration就能看到完整的错误堆栈，这会帮你更快定位隐藏问题。

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