ServiceBus触发Azure函数中SqlServerRetryingExecutionStrategy异常排查

在ServiceBus触发的Azure Function中间歇性遇到InvalidOperationException异常，错误提示如下：

已配置的执行策略'SqlServerRetryingExecutionStrategy'不支持用户发起的事务。请使用'DbContext.Database.CreateExecutionStrategy()'返回的执行策略，将事务中的所有操作作为可重试单元执行。

代码逻辑非常简单，未主动发起任何用户事务：

try
{
    Context.Add<TEntity>(entity);
    await Context.SaveChangesAsync();
}
catch (Exception ex)
{
    ...
}

DbContext通过依赖注入注册为Scoped模式。现有资料均指向用户主动发起事务的场景，但当前代码不存在该情况，疑问如下：

• 引发该异常是否存在其他原因？
• 是否存在某些场景下SaveChanges操作会被判定为用户发起的事务？
• 存储过程中的事务是否可能导致该问题？

1. Azure Function的Scoped上下文被意外复用 #

ServiceBus触发的Azure Function在宿主优化场景（如实例复用、连接池复用）下，可能导致Scoped生命周期的DbContext未被正确释放，后续请求复用该上下文时，若之前的操作残留了未完成的事务状态（比如异常导致事务未正常终结），就会触发错误。

解决方式：

• 确保依赖注入配置正确，DbContext严格遵循Scoped生命周期，避免在Singleton服务中引用Scoped的DbContext。
• 在Function逻辑结束前，可显式清理上下文状态：Context.ChangeTracker.Clear()，避免残留的变更或事务影响后续请求。

2. EF Core自动事务的冲突场景 #

虽然你没有显式调用BeginTransaction，但EF Core在SaveChangesAsync时会自动开启事务：当操作涉及多个变更（比如级联操作、批量实体新增），或者数据库提供者要求原子性操作时，EF会自动创建事务。此时如果SqlServerRetryingExecutionStrategy的重试逻辑与自动事务的处理逻辑冲突，就可能间歇性触发错误。

解决方式：

• 显式使用执行策略包裹SaveChanges操作，将自动事务纳入重试单元：

await Context.Database.CreateExecutionStrategy().ExecuteAsync(async () =>
{
    Context.Add<TEntity>(entity);
    await Context.SaveChangesAsync();
});

• 检查实体配置，若存在级联删除/更新规则，确认这些操作是否会触发多SQL语句，导致自动事务的范围超出预期。

3. 存储过程/触发器的事务干扰 #

如果SaveChanges触发的SQL操作调用了包含显式事务的存储过程，或者数据库触发器中开启了独立事务，EF Core的自动事务会与这些内部事务形成嵌套，而SqlServerRetryingExecutionStrategy不支持嵌套事务，从而触发错误。

解决方式：

• 排查数据库中的存储过程、触发器，移除不必要的显式BEGIN TRANSACTION/COMMIT语句，让事务由EF Core统一管理。
• 若必须在存储过程中使用事务，可禁用EF的自动事务（Context.Database.AutoTransactionsEnabled = false），但需自行保证操作的原子性。

4. DbContext执行策略配置问题 #

如果注册DbContext时，未正确绑定SqlServerRetryingExecutionStrategy与上下文的事务逻辑，或者执行策略被错误覆盖，也可能导致事务兼容性问题。

解决方式：

• 确认DI注册代码中执行策略的配置正确：

services.AddDbContext<YourDbContext>(options => 
    options.UseSqlServer(connectionString)
           .UseSqlServerRetryingExecutionStrategy(), 
    ServiceLifetime.Scoped);

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