在Azure耐用函数协调器中使用异步帮助程序函数是否安全? [英] Is it safe to use async helper functions in an Azure Durable Functions Orchestator?

查看:112
本文介绍了在Azure耐用函数协调器中使用异步帮助程序函数是否安全?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图在我们的持久功能项目中查找一些偶然的Non-Deterministic workflow detected: TaskScheduledEvent: 0 TaskScheduled ...错误.它很少见(在10,000左右的实例中为3次).

I am trying to track down some occasional Non-Deterministic workflow detected: TaskScheduledEvent: 0 TaskScheduled ... errors in a durable function project of ours. It is infrequent (3 times in 10,000 or so instances).

在将协调器代码与约束进行比较时

When comparing the orchestrator code to the constraints documented here there is one pattern we use that I am not clear on. In an effort to make the orchestrator code more clean/readable we use some private async helper functions to make the actual CallActivityWithRetryAsync call, sometimes wrapped in an exception handler for logging, then the main orchestrator function awaits on this helper function.

类似于以下简化示例的东西:

Something like this simplified sample:

[FunctionName(Name)]
public static async Task RunPipelineAsync(
    [OrchestrationTrigger]
    DurableOrchestrationContextBase context,

    ILogger log)
{
    // other steps

    await WriteStatusAsync(context, "Started", log);

    // other steps

    await WriteStatusAsync(context, "Completed", log);
}

private static async Task WriteStatusAsync(
    DurableOrchestrationContextBase context,
    string status,
    ILogger log
)
{
    log.LogInformationOnce(context, "log message...");
    try
    {
        var request = new WriteAppDocumentStatusRequest 
        {
            //...
        };

        await context.CallActivityWithRetryAsync(
            "WriteAppStatus",
            RetryPolicy,
            request
        );
    }
    catch(Exception e)
    {
        // "optional step" will log errors but not take down the orchestrator
        // log here
    }
}

实际上,这些任务被组合在一起并与Task.WhenAll一起使用.尽管实际上不是在context上直接 调用这些async函数是否有效?

In reality these tasks are combined and used with Task.WhenAll. Is it valid to be calling these async functions despite the fact that they are not directly on the context?

推荐答案

是的,您所做的事情非常安全,因为它仍然会导致确定性行为.只要您不执行任何自定义线程调度或调用具有自己单独的异步回调(例如,网络API通常在单独的线程上运行的回调)的非持久性API,就可以了.

Yes, what you're doing is perfectly safe because it still results in deterministic behavior. As long as you aren't doing any custom thread scheduling or calling non-durable APIs that have their own separate async callbacks (for example, network APIs typically have callbacks running on a separate thread), you are fine.

如果不确定,我强烈建议您使用我们的耐用功能C#分析器,可以分析您的代码是否存在编码错误.这将有助于标记可能导致Non-deterministic workflow错误的所有编码错误.

If you are ever unsure, I highly recommend you use our Durable Functions C# analyzer to analyzer your code for coding errors. This will help flag any coding mistakes that could result in Non-deterministic workflow errors.

更新

注意:当前版本的分析器将要求您向私有异步函数添加[Deterministic]属性,如下所示:

Note: the current version of the analyzer will require you to add a [Deterministic] attribute to your private async function, like this:

[Deterministic]
private static async Task WriteStatusAsync(
    DurableOrchestrationContextBase context,
    string status,
    ILogger log
)
{
   // ...
}

这使您知道协调器函数正在使用私有异步方法,并且还需要对其进行分析.如果您使用的是耐用功能1.8.3或更低版本,则[Deterministic]属性将不存在.但是,您可以使用相同的名称创建自己的自定义属性,分析器会接受该属性.例如:

This lets it know that the private async method is being used by your orchestrator function and that it also needs to be analyzed. If you're using Durable Functions 1.8.3 or below, the [Deterministic] attribute will not exist. However, you can create your own custom attribute with the same name and the analyzer will honor it. For example:

[Deterministic]
private static async Task WriteStatusAsync(
    DurableOrchestrationContextBase context,
    string status,
    ILogger log
)
{
   // ...
}

// Needed for the Durable Functions analyzer
class Deterministic : Attribute { }

但是请注意,我们计划在将来的版本中删除对[Deterministic]属性的需要,因为我们发现实际上并没有必要.

Note, however, that we are planning on removing the need for the [Deterministic] attribute in a future release, as we're finding it may not actually be necessary.

这篇关于在Azure耐用函数协调器中使用异步帮助程序函数是否安全?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆