Azure Event Grid Trigger Function 500错误重试与死信队列配置

Event Grid判定事件投递成功的唯一标准是：订阅接收方在配置的请求超时窗口内返回2xx范围的状态码。你观测到失败事件被标记为已投递的核心原因是：EventGridTrigger触发函数执行后，函数内部调用下游API产生的异常没有透传回Functions运行时的触发器绑定层，导致触发器默认向Event Grid返回了200 OK响应，Event Grid收到成功响应后自然不会触发重试，也不会流转死信逻辑。

只有让Event Grid收到非2xx的失败响应，才会触发重试逻辑，函数端需要做如下调整：

• 禁止全局吞掉调用下游API的所有异常。不要用无返回的try-catch块包裹下游调用逻辑，比如类似try{ await 下游调用 }catch(Exception ex){ log.LogError(ex); return; }的写法会直接让函数正常退出，触发器默认返回成功响应。
• 下游API返回5xx类错误、连接失败、请求超时等场景下，必须直接抛出未处理异常（比如原生HttpRequestException、自定义业务异常），不要手动返回OkResult类的成功响应。未处理异常会被Functions运行时自动捕获，向Event Grid返回500 Internal Server Error，触发Event Grid的失败判定。
• 如果你使用的是隔离工作进程（Isolated Worker）模型的Azure Function，不要在全局异常中间件中将所有异常统一转换为200响应，必须保留5xx类失败状态码返回。

Event Grid默认开启重试逻辑，你可以在对应主题的事件订阅配置页按需调整重试参数：

• 最大重试次数：支持配置1-30次，默认值为30次
• 事件生存时间（TTL）：支持配置1分钟到24小时，默认值为24小时，超过TTL未成功投递的事件会进入死信流程
• 重试间隔策略：
  • 固定间隔：每次重试间隔固定，可配置范围为10分钟到1小时
  • 指数退避：默认策略，重试间隔按指数级增长，内置随机抖动避免下游服务出现请求风暴

注意：如果函数返回4xx类错误（如参数格式非法、权限不足），Event Grid会判定为不可恢复错误，不会触发重试，直接进入后续死信判断流程。

死信队列用于存储超过重试次数、超过TTL仍无法成功投递的事件，避免事件丢失，配置步骤如下：

1. 提前准备存储资源作为死信存储目标，支持选择存储账户Blob容器、Service Bus队列/主题等
2. 进入Event Grid对应主题的事件订阅列表，找到绑定目标Azure Function的订阅条目，进入配置编辑页
3. 找到「死信设置」板块，开启死信功能，选择提前准备好的存储目标，给Event Grid服务主体分配对应存储资源的写入权限
4. 保存配置后，所有最终投递失败的事件会自动写入配置的死信位置，可后续手动排查补偿。

• 函数执行超时配置需要短于Event Grid的投递超时时间，否则Event Grid会提前判定请求超时触发重试，可能导致函数逻辑重复执行，需要提前做好业务幂等处理。
• 如果在事件订阅高级配置中开启了手动确认模式，需要在函数逻辑中主动向Event Grid返回NACK响应才会触发重试；默认的自动确认模式下，只要函数抛出未处理异常就会自动返回NACK。
• 不要在函数内对所有异常做降级返回成功的处理，否则所有失败场景都会被Event Grid误判为投递成功。

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