Configurable queue polling delays

[cgillum]

Background

There have been several issues opened relating to queue polling in Durable Functions. They fall under two general categories:

• Wanting longer polling delays to mitigate cost
• Wanting shorter polling delays to mitigate end-to-end latency

Of the two, cost mitigation is the more common ask, but both are very much valid.

There are three sources of polling in the end-to-end system:

1. Individual control queue polling (there is one polling loop per partition)
2. Work item queue polling
3. Scale Controller polling in the Azure Functions Consumption and Premium plans

Issue

The Durable Functions extension does not currently provide any mechanism to configure the queue polling delays, which means that customers have no control. This work item tracks allowing configuration for the above delays so that both cost-savings and end-to-end latency can be controlled by customers.

Related:

• Long delay between starting and triggering orchestration function #606
• Durable Function storage usage when idle #391

[cgillum]

There are at least two places needed to make this work:

Durable Task Framework - Azure Storage Provider

Currently a hardcoded polling interval is used here. Instead of being hardcoded, it should come from AzureStorageOrchestrationServiceSettings. The new property can be named the same as the existing constant: MaxQueuePollingDelay. The constant can then be moved into AzureStorageOrchestrationServiceSettings and used as the default value.

Durable Task Extension for Azure Functions

A new property needs to be added to DurableTaskExtension which controls the polling behavior. By simply adding a new public property, it automatically becomes configurable via host.json. The value of this new property needs to be assigned to the corresponding property in the AzureStorageOrchestrationServiceSettings object here