Edit

Share via


Bindings for Durable Functions (Azure Functions)

The Durable Functions extension introduces three trigger bindings that control the execution of orchestrator, entity, and activity functions. It also introduces an output binding that acts as a client for the Durable Functions runtime.

This article discusses the use of these four bindings and provides code samples. It also provides information about the Durable Functions configuration properties in host.json, the metadata file that contains settings that affect all functions in a function app.

Make sure to select your Durable Functions development language at the top of the article.

Both versions of the Python programming model for Azure Functions are supported by Durable Functions. Because Python v2 is the recommended version, examples in this article exclusively feature this version.

Prerequisites

  • Durable Functions SDK, which is the Python Package Index (PyPI) package azure-functions-durable, version 1.2.2 or a later version
  • Extension bundle version 4.x (or a later version), which is set in the host.json project file

You can provide feedback and suggestions in the Durable Functions SDK for Python repository.

Orchestration trigger

You can use the orchestration trigger to develop durable orchestrator functions. This trigger executes when a new orchestration instance is scheduled and when an existing orchestration instance receives an event. Examples of events that can trigger orchestrator functions include durable timer expirations, activity function responses, and events raised by external clients.

When you develop functions in .NET, you use the OrchestrationTriggerAttribute .NET attribute to configure the orchestration trigger.

For Java, you use the @DurableOrchestrationTrigger annotation to configure the orchestration trigger.

When you use version 4 of the Node.js programming model to develop functions, you import the app object from the @azure/functions npm module. Then you call the app.orchestration method of the Durable Functions API directly in your function code. This method registers your orchestrator function with the Durable Functions framework.

When you write orchestrator functions, you define the orchestration trigger by using the following JSON object in the bindings array of the function.json file:

{
    "name": "<name-of-input-parameter-in-function-signature>",
    "orchestration": "<optional-name-of-orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}

The orchestration value is the name of the orchestration that clients must use when they want to start new instances of the orchestrator function. This property is optional. If you don't specify it, the name of the function is used.

When you use the Python v2 programming model, you can define an orchestration trigger by using the orchestration_trigger decorator directly in your Python function code.

In the v2 model, you access the Durable Functions triggers and bindings from an instance of DFApp. You can use this subclass of FunctionApp to export decorators that are specific to Durable Functions.

Internally, this trigger binding polls the configured durable store for new orchestration events. Examples of events include orchestration start events, durable timer expiration events, activity function response events, and external events raised by other functions.

Trigger behavior

Here are some notes about the orchestration trigger:

  • Single-threading: A single dispatcher thread is used for all orchestrator function execution on a single host instance. For this reason, it's important to ensure that orchestrator function code is efficient and doesn't perform any I/O operations. It's also important to ensure that this thread doesn't do any asynchronous work except when awaiting task types that are specific to Durable Functions.
  • Poison-message handling: There's no support for poison messages in orchestration triggers.
  • Message visibility: Orchestration trigger messages are dequeued and kept invisible for a configurable duration. The visibility of these messages is renewed automatically as long as the function app is running and healthy.
  • Return values: Return values are serialized to JSON and persisted to the orchestration history table in Azure Table Storage. These return values can be queried by the orchestration client binding, described later.

Warning

Orchestrator functions should never use any input or output bindings other than the orchestration trigger binding. Using other bindings can cause problems with the Durable Task extension, because those bindings might not obey the single-threading and I/O rules. If you want to use other bindings, add them to an activity function called from your orchestrator function. For more information about coding constraints for orchestrator functions, see Orchestrator function code constraints.

Warning

Orchestrator functions should never be declared async.

Trigger usage

The orchestration trigger binding supports both inputs and outputs. Here are some notes about input and output handling:

  • Inputs: You can invoke orchestration triggers that have inputs. The inputs are accessed through the context input object. All inputs must be JSON-serializable.
  • Outputs: Orchestration triggers support both output and input values. The return value of the function is used to assign the output value. The return value must be JSON-serializable.

Trigger sample

The following code provides an example of a basic Hello World orchestrator function. This example orchestrator doesn't schedule any tasks.

The attribute that you use to define the trigger depends on whether you run your C# functions in the same process as the Functions host process or in an isolated worker process.

[FunctionName("HelloWorld")]
public static string RunOrchestrator([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    return $"Hello {name}!";
}

Note

The preceding code is for Durable Functions 2.x. For Durable Functions 1.x, you must use DurableOrchestrationContext instead of IDurableOrchestrationContext. For more information about the differences between versions, see Durable Functions versions overview.

const { app } = require('@azure/functions');
const df = require('durable-functions');

df.app.orchestration('helloOrchestrator', function* (context) {
    const name = context.df.getInput();
    return `Hello ${name}`;
});

Note

The durable-functions library calls the synchronous context.done method when the generator function exits.

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.orchestration_trigger(context_name="context")
def my_orchestrator(context):
    result = yield context.call_activity("Hello", "Tokyo")
    return result
param($Context)

$InputData = $Context.Input
$InputData
@FunctionName("HelloWorldOrchestration")
public String helloWorldOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    return String.format("Hello %s!", ctx.getInput(String.class));
}

Most orchestrator functions call activity functions. The following code provides a Hello World example that demonstrates how to call an activity function:

[FunctionName("HelloWorld")]
public static async Task<string> RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    string result = await context.CallActivityAsync<string>("SayHello", name);
    return result;
}

Note

The preceding code is for Durable Functions 2.x. For Durable Functions 1.x, you must use DurableOrchestrationContext instead of IDurableOrchestrationContext. For more information about the differences between versions, see Durable Functions versions overview.

const { app } = require('@azure/functions');
const df = require('durable-functions');

const activityName = 'hello';

df.app.orchestration('helloOrchestrator', function* (context) {
    const name = context.df.getInput();
    const result = yield context.df.callActivity(activityName, name);
    return result;
});
@FunctionName("HelloWorld")
public String helloWorldOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    String input = ctx.getInput(String.class);
    String result = ctx.callActivity("SayHello", input, String.class).await();
    return result;
}

Activity trigger

You can use the activity trigger to develop functions known as activity functions that are called by orchestrator functions.

You use the ActivityTriggerAttribute .NET attribute to configure the activity trigger.

You use the @DurableActivityTrigger annotation to configure the activity trigger.

To register your activity function, you import the app object from the @azure/functions npm module. Then you call the app.activity method of the Durable Functions API directly in your function code.

To define the activity trigger, you use the following JSON object in the bindings array of function.json:

{
    "name": "<name-of-input-parameter-in-function-signature>",
    "activity": "<optional-name-of-activity>",
    "type": "activityTrigger",
    "direction": "in"
}

The activity value is the name of the activity. This value is the name that orchestrator functions use to invoke this activity function. This property is optional. If you don't specify it, the name of the function is used.

You can define an activity trigger by using the activity_trigger decorator directly in your Python function code.

Internally, this trigger binding polls the configured durable store for new activity execution events.

Trigger behavior

Here are some notes about the activity trigger:

  • Threading: Unlike the orchestration trigger, activity triggers don't have any restrictions on threading or I/O operations. They can be treated like regular functions.
  • Poison-message handling: There's no support for poison messages in activity triggers.
  • Message visibility: Activity trigger messages are dequeued and kept invisible for a configurable duration. The visibility of these messages is renewed automatically as long as the function app is running and healthy.
  • Return values: Return values are serialized to JSON and persisted to the configured durable store.

Trigger usage

The activity trigger binding supports both inputs and outputs, just like the orchestration trigger. Here are some notes about input and output handling:

  • Inputs: Activity triggers can be invoked with inputs from an orchestrator function. All inputs must be JSON-serializable.
  • Outputs: Activity functions support both output and input values. The return value of the function is used to assign the output value and must be JSON-serializable.
  • Metadata: .NET activity functions can bind to a string instanceId parameter to get the instance ID of the calling orchestration.

Trigger sample

The following code provides an example of a basic Hello World activity function.

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] IDurableActivityContext helloContext)
{
    string name = helloContext.GetInput<string>();
    return $"Hello {name}!";
}

The default parameter type for the .NET ActivityTriggerAttribute binding is IDurableActivityContext (or DurableActivityContext for Durable Functions 1.x). However, .NET activity triggers also support binding directly to JSON-serializeable types (including primitive types), so you can also use the following simplified version of the function:

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] string name)
{
    return $"Hello {name}!";
}
const { app } = require('@azure/functions');
const df = require('durable-functions');
const activityName = 'hello';
df.app.activity(activityName, {
    handler: (input) => {
        return `Hello, ${input}`;
    },
});
import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.activity_trigger(input_name="myInput")
def my_activity(myInput: str):
    return "Hello " + myInput
param($name)

"Hello $name!"
@FunctionName("SayHello")
public String sayHello(@DurableActivityTrigger(name = "name") String name) {
    return String.format("Hello %s!", name);
}

Use input and output bindings

Besides the activity trigger binding, you can also use regular input and output bindings.

For example, an activity function can receive input from an orchestrator function. The activity function can then send that input as a message to Azure Event Hubs.

const { app } = require('@azure/functions');
const df = require('durable-functions');

df.app.orchestration('helloOrchestrator', function* (context) {
    const input = context.df.getInput();
    yield context.df.callActivity('sendToEventHub', input);
    return `Message sent: ${input}`;
});

const { EventHubProducerClient } = require("@azure/event-hubs");
const connectionString = process.env.EVENT_HUB_CONNECTION_STRING;
const eventHubName = process.env.EVENT_HUB_NAME;

df.app.activity("sendToEventHub", {
    handler: async (message, context) => {
        const producer = new EventHubProducerClient(connectionString, eventHubName);
        try {
            const batch = await producer.createBatch();
            batch.tryAdd({ body: message });
            await producer.sendBatch(batch);
            context.log(`Message sent to Event Hubs: ${message}`);
        } catch (err) {
            context.log.error("Failed to send message to Event Hubs:", err);
            throw err;
        } finally {
            await producer.close();
        }
    },
});

app.storageQueue('helloQueueStart', {
    queueName: 'start-orchestration',
    extraInputs: [df.input.durableClient()],
    handler: async (message, context) => {
        const client = df.getClient(context);
        const orchestratorName = message.orchestratorName || 'helloOrchestrator';
        const input = message.input || null;
        const instanceId = await client.startNew(orchestratorName, { input });
        context.log(`Started orchestration with ID = '${instanceId}'`);
    },
});

Orchestration client

You can use the orchestration client binding to write functions that interact with orchestrator functions. These functions are often referred to as client functions. For example, you can act on orchestration instances in the following ways:

  • Start them.
  • Query their status.
  • Terminate them.
  • Send events to them while they're running.
  • Purge the instance history.

You can bind to an orchestration client by using the DurableClientAttribute attribute (OrchestrationClientAttribute in Durable Functions 1.x).

You can bind to an orchestration client by using the @DurableClientInput annotation.

To register your client function, you import the app object from the @azure/functions npm module. Then you call a Durable Functions API method that's specific to your trigger type. For instance, for an HTTP trigger, you call the app.http method. For a queue trigger, you call the app.storageQueue method.

To define the durable client trigger, you use the following JSON object in the bindings array of function.json:

{
    "name": "<name-of-input-parameter-in-function-signature>",
    "taskHub": "<optional-name-of-task-hub>",
    "connectionName": "<optional-name-of-connection-string-app-setting>",
    "type": "orchestrationClient",
    "direction": "in"
}
  • The taskHub property is used when multiple function apps share the same storage account but need to be isolated from each other. If you don't specify this property, the default value from host.json is used. This value must match the value that the target orchestrator functions use.
  • The connectionName value is the name of an app setting that contains a storage account connection string. The storage account represented by this connection string must be the same one that the target orchestrator functions use. If you don't specify this property, the default storage account connection string for the function app is used.

Note

In most cases, we recommend that you omit these properties and rely on the default behavior.

You can define a durable client trigger by using the durable_client_input decorator directly in your Python function code.

Client usage

You typically bind to an implementation of IDurableClient (DurableOrchestrationClient in Durable Functions 1.x), which gives you full access to all orchestration client APIs that Durable Functions supports.

You typically bind to the DurableClientContext class.

You must use the language-specific SDK to get access to a client object.

The following code provides an example of a queue-triggered function that starts a Hello World orchestration.

[FunctionName("QueueStart")]
public static Task Run(
    [QueueTrigger("durable-function-trigger")] string input,
    [DurableClient] IDurableOrchestrationClient starter)
{
    // Orchestration input comes from the queue message content.
    return starter.StartNewAsync<string>("HelloWorld", input);
}

Note

The preceding C# code is for Durable Functions 2.x. For Durable Functions 1.x, you must use the OrchestrationClient attribute instead of the DurableClient attribute, and you must use the DurableOrchestrationClient parameter type instead of IDurableOrchestrationClient. For more information about the differences between versions, see Durable Functions versions overview.

const { app } = require('@azure/functions');
const df = require('durable-functions');

app.storageQueue('helloQueueStart', {
    queueName: 'start-orchestration',
    extraInputs: [df.input.durableClient()],
    handler: async (message, context) => {
        const client = df.getClient(context);
        const orchestratorName = message.orchestratorName || 'helloOrchestrator';
        const input = message.input || null;
        const instanceId = await client.startNew(orchestratorName, { input });
        context.log(`Started orchestration with ID = '${instanceId}' from queue message.`);
    },
});
import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.queue_trigger(
    arg_name="msg",
    queue_name="start-orchestration",
    connection="AzureWebJobsStorage"
)
@myApp.durable_client_input(client_name="client")
async def client_function(msg: func.QueueMessage, client: df.DurableOrchestrationClient):
    input_data = msg.get_body().decode("utf-8")
    await client.start_new("my_orchestrator", None, input_data)
    return None

function.json

{
  "bindings": [
    {
      "name": "InputData",
      "type": "queueTrigger",
      "queueName": "durable-function-trigger",
      "direction": "in"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in"
    }
  ]
}

run.ps1

param([string]$InputData, $TriggerMetadata)

$InstanceId = Start-DurableOrchestration -FunctionName 'HelloWorld' -Input $InputData
@FunctionName("QueueStart")
public void queueStart(
        @QueueTrigger(name = "input", queueName = "durable-function-trigger", connection = "Storage") String input,
        @DurableClientInput(name = "durableContext") DurableClientContext durableContext) {
    // Orchestration input comes from the queue message content.
    durableContext.getClient().scheduleNewOrchestrationInstance("HelloWorld", input);
}

For detailed information about starting instances, see Manage instances in Durable Functions in Azure.

Entity trigger

You can use the entity trigger to develop an entity function. This trigger supports processing events for a specific entity instance.

Note

Entity triggers are available starting in Durable Functions 2.x.

Internally, this trigger binding polls the configured durable store for new entity operations that need to be executed.

You use the EntityTriggerAttribute .NET attribute to configure the entity trigger.

To register the entity trigger, you import the app object from the @azure/functions npm module. Then you call the app.entity method of the Durable Functions API directly in your function code.

const df = require('durable-functions');
df.app.entity('counter', (context) => {
    const currentValue = context.df.getState(() => 0);
    switch (context.df.operationName) {
        case 'add':
            context.df.setState(currentValue + context.df.getInput());
            break;
        case 'reset':
            context.df.setState(0);
            break;
        case 'get':
            context.df.return(currentValue);
            break;
    }
});

Note

Entity triggers aren't yet supported for Java.

Note

Entity triggers aren't yet supported for PowerShell.

You can define an entity trigger by using the entity_trigger decorator directly in your Python function code.

Trigger behavior

Here are some notes about the entity trigger:

  • Single-threading: A single dispatcher thread is used to process operations for a particular entity. If multiple messages are sent to a single entity concurrently, the operations are processed one at a time.
  • Poison-message handling: There's no support for poison messages in entity triggers.
  • Message visibility: Entity trigger messages are dequeued and kept invisible for a configurable duration. The visibility of these messages is renewed automatically as long as the function app is running and healthy.
  • Return values: Entity functions don't support return values. There are specific APIs that you can use to save state or pass values back to orchestrations.

Any state changes made to an entity during its execution are automatically persisted after execution is complete.

For more information and examples of defining and interacting with entity triggers, see Entity functions.

Entity client

You can use the entity client binding to asynchronously trigger entity functions. These functions are sometimes referred to as client functions.

You can bind to the entity client by using the DurableClientAttribute .NET attribute in .NET class library functions.

Note

You can also use the [DurableClientAttribute] to bind to the orchestration client.

Instead of registering an entity client, you use signalEntity or callEntity to call an entity trigger method from any registered function.

  • From a queue-triggered function, you can use client.signalEntity:

    const { app } = require('@azure/functions');
    const df = require('durable-functions');
    app.storageQueue('helloQueueStart', {
        queueName: 'start-orchestration',
        extraInputs: [df.input.durableClient()],
        handler: async (message, context) => {
            const client = df.getClient(context);
            const entityId = new df.EntityId('counter', 'myCounter');
            await client.signalEntity(entityId, 'add', 5);
        },
    });
    
  • From an orchestrator function, you can use context.df.callEntity:

    const { app } = require('@azure/functions');
    const df = require('durable-functions');
    df.app.orchestration('entityCaller', function* (context) {
        const entityId = new df.EntityId('counter', 'myCounter');
        yield context.df.callEntity(entityId, 'add', 5);
        yield context.df.callEntity(entityId, 'add', 5);
        const result = yield context.df.callEntity(entityId, 'get');
        return result;
    });
    

You can define an entity client by using the durable_client_input decorator directly in your Python function code.

Note

Entity clients aren't yet supported for Java.

Note

Entity clients aren't yet supported for PowerShell.

For more information and examples of interacting with entities as a client, see Access entities.

Durable Functions settings in host.json

This section provides information about the Durable Functions configuration properties in host.json. For information about general settings in host.json, see host.json reference for Azure Functions 1.x or host.json reference for Azure Functions 2.x and later.

Configuration settings for Durable Functions.

Note

All major versions of Durable Functions are supported on all versions of the Azure Functions runtime. However, the schema of the host.json configuration differs slightly depending on the version of the Azure Functions runtime and the version of the Durable Functions extension that you use.

The following code provides two examples of durableTask settings in host.json: one for Durable Functions 2.x and one for Durable Functions 1.x. You can use both examples with Azure Functions 2.0 and 3.0. With Azure Functions 1.0, the available settings are the same, but the durableTask section of host.json is located in the root of the host.json configuration instead of being a field under extensions.

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "defaultVersion": "1.0",
    "versionMatchStrategy": "CurrentOrOlder",
    "versionFailureStrategy": "Reject",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "FetchLargeMessagesAutomatically": true,
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": false,
      "useTablePartitionManagement": true,
      "workItemQueueVisibilityTimeout": "00:05:00",
      "QueueClientMessageEncoding": "UTF8"
    },
    "tracing": {
      "traceInputsAndOutputs": false,
      "traceReplayEvents": false,
    },
    "notifications": {
      "eventGrid": {
        "topicEndpoint": "https://topic_name.westus2-1.eventgrid.azure.net/api/events",
        "keySettingName": "EventGridKey",
        "publishRetryCount": 3,
        "publishRetryInterval": "00:00:30",
        "publishEventTypes": [
          "Started",
          "Completed",
          "Failed",
          "Terminated"
        ]
      }
    },
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10,
    "maxConcurrentEntityFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "maxOrchestrationActions": 100000,
    "storeInputsInOrchestrationHistory": false
  }
 }
}
Property Default value Description
hubName TestHubName (DurableFunctionsHub in v1.x) The name of the hub that stores the current state of a function app. Task hub names must start with a letter and consist of only letters and numbers. If you don't specify a name, the default value is used. Alternate task hub names can be used to isolate multiple Durable Functions applications from each other, even if they use the same storage back end. For more information, see Task hubs.
defaultVersion The default version to assign to new orchestration instances. When you specify a version, new orchestration instances are permanently associated with this version value. This setting is used by the orchestration versioning feature to enable scenarios like zero-downtime deployments with breaking changes. You can use any string value for the version.
versionMatchStrategy CurrentOrOlder A value that specifies how orchestration versions are matched when orchestrator functions are loaded. Valid values are None, Strict, and CurrentOrOlder. For detailed explanations, see Orchestration versioning.
versionFailureStrategy Reject A value that specifies what happens when an orchestration version doesn't match the current defaultVersion value. Valid values are Reject and Fail. For detailed explanations, see Orchestration versioning.
controlQueueBatchSize 32 The number of messages to pull from the control queue at a time.
controlQueueBufferThreshold Consumption plan for Python: 32
Consumption plan for other languages: 128
Dedicated or Premium plan: 256
The number of control queue messages that can be buffered in memory at a time. When the specified number is reached, the dispatcher waits before dequeuing any other messages. In some situations, reducing this value can significantly reduce memory consumption.
partitionCount 4 The partition count for the control queue. This value must be a positive integer between 1 and 16. Changing this value requires configuring a new task hub.
controlQueueVisibilityTimeout 00:05:00 The visibility timeout of dequeued control queue messages in hh:mm:ss format.
workItemQueueVisibilityTimeout 00:05:00 The visibility timeout of dequeued work item queue messages in hh:mm:ss format.
FetchLargeMessagesAutomatically true A value that specifies whether to retrieve large messages in orchestration status queries. When this setting is true, large messages that exceed the queue size limit are retrieved. When this setting is false, a blob URL that points to each large message is retrieved.
maxConcurrentActivityFunctions Consumption plan: 10
Dedicated or Premium plan: 10 times the number of processors on the current machine
The maximum number of activity functions that can be processed concurrently on a single host instance.
maxConcurrentOrchestratorFunctions Consumption plan: 5
Dedicated or Premium plan: 10 times the number of processors on the current machine
The maximum number of orchestrator functions that can be processed concurrently on a single host instance.
maxConcurrentEntityFunctions Consumption plan: 5
Dedicated or Premium plan: 10 times the number of processors on the current machine
The maximum number of entity functions that can be processed concurrently on a single host instance. This setting is applicable only when you use the durable task scheduler. Otherwise, the maximum number of concurrent entity executions is limited to the maxConcurrentOrchestratorFunctions value.
maxQueuePollingInterval 00:00:30 The maximum control and work-item queue polling interval in hh:mm:ss format. Higher values can result in higher message processing latencies. Lower values can result in higher storage costs because of increased storage transactions.
maxOrchestrationActions 100,000 The maximum number of actions an orchestrator function can perform during a single execution cycle.
connectionName (v2.7.0 and later)
connectionStringName (v2.x)
azureStorageConnectionStringName (v1.x)
AzureWebJobsStorage The name of an app setting or setting collection that specifies how to connect to the underlying Azure Storage resources. When you provide a single app setting, it should be an Azure Storage connection string.
trackingStoreConnectionName (v2.7.0 and later)
trackingStoreConnectionStringName
The name of an app setting or setting collection that specifies how to connect to the History and Instances tables, which store the execution history and metadata about orchestration instances. When you provide a single app setting, it should be an Azure Storage connection string. If you don't specify a setting, the connectionStringName value (v2.x) or azureStorageConnectionStringName value (v1.x) connection is used.
trackingStoreNamePrefix The prefix to use for the History and Instances tables when trackingStoreConnectionStringName is specified. If you don't specify a prefix, the default value of DurableTask is used. If trackingStoreConnectionStringName isn't specified, the History and Instances tables use the hubName value as their prefix, and the trackingStoreNamePrefix setting is ignored.
traceInputsAndOutputs false A value that indicates whether to trace the inputs and outputs of function calls. When function execution events are traced, the default behavior is to include the number of bytes in the serialized inputs and outputs for function calls. This behavior provides minimal information about the inputs and outputs so that it doesn't bloat the logs or inadvertently expose sensitive information. When this property is true, the entire contents of function inputs and outputs are logged.
traceReplayEvents false A value that indicates whether to write orchestration replay events to Application Insights.
logReplayEvents false A value that indicates whether to log replayed executions in application logs.
eventGridTopicEndpoint The URL of an Azure Event Grid custom topic endpoint. When you set this property, orchestration lifecycle notification events are published to this endpoint. This property supports app settings resolution.
eventGridKeySettingName The name of the app setting that contains the key used for authenticating with the Event Grid custom topic at the EventGridTopicEndpoint URL.
eventGridPublishRetryCount 0 The number of times to retry if publishing to the Event Grid topic fails.
eventGridPublishRetryInterval 00:05:00 The Event Grid publish-retry interval in hh:mm:ss format.
eventGridPublishEventTypes A list of event types to publish to Event Grid. If you don't specify any types, all event types are published. Allowed values include Started, Completed, Failed, and Terminated.
extendedSessionsEnabled false A value that specifies whether session orchestrator and entity function sessions are cached.
extendedSessionIdleTimeoutInSeconds 30 The number of seconds an idle orchestrator or entity function remains in memory before being unloaded. This setting is only used when the extendedSessionsEnabled setting is true.
useAppLease true A value that indicates whether apps must acquire an app-level blob lease before processing task hub messages. For more information, see Disaster recovery and geo-distribution in Durable Functions. This setting is available starting in v2.3.0.
useLegacyPartitionManagement false A value that specifies the type of partition management algorithm to use. When this setting is false, an algorithm is used that reduces the possibility of duplicate function execution when scaling out. This setting is available starting in v2.3.0. Setting this value to true isn't recommended.
useTablePartitionManagement In v3.x: true
In v2.x: false
A value that specifies the type of partition management algorithm to use. When this setting is true, an algorithm is used that's designed to reduce costs for Azure Storage v2 accounts. This setting is available starting in WebJobs.Extensions.DurableTask v2.10.0. Using this setting with a managed identity requires WebJobs.Extensions.DurableTask v3.x or later, or Worker.Extensions.DurableTask v1.2.x or later.
useGracefulShutdown false (Preview) A value that indicates whether to shut down gracefully to reduce the chance of host shutdowns causing in-process function executions to fail.
maxEntityOperationBatchSize Consumption plan: 50
Dedicated or Premium plan: 5,000
The maximum number of entity operations that are processed as a batch. If this value is 1, batching is disabled, and a separate function invocation processes each operation message. This setting is available starting in v2.6.1.
storeInputsInOrchestrationHistory false A value that specifies how to store inputs. When this setting is true, the Durable Task Framework saves activity inputs in the History table, and activity function inputs appear in orchestration history query results.
maxGrpcMessageSizeInBytes 4,194,304 An integer value that sets the maximum size, in bytes, of messages that the generic Remote Procedure Call (gRPC) client can receive. The implementation of DurableTaskClient uses the gRPC client to manage orchestration instances. This setting applies to Durable Functions .NET isolated worker and Java apps.
grpcHttpClientTimeout 00:01:40 The timeout in hh:mm:ss format for the HTTP client used by the gRPC client in Durable Functions. The client is currently supported for .NET isolated worker apps (.NET 6 and later versions) and for Java apps.
QueueClientMessageEncoding UTF8 The encoding strategy for Azure Queue Storage messages. Valid strategies are Unicode Transformation Format–8-bit (UTF8) and Base64. This setting applies when you use Microsoft.Azure.WebJobs.Extensions.DurableTask 3.4.0 or later, or Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.7.0 or later.

Many of these settings are for optimizing performance. For more information, see Performance and scale.

Next steps