Scaled azure function with cosmosdb trigger remains idle

Question

We have Azure function hosted in AKS, with CosmosDb trigger.

Have added polly retry in function in case of failure - granted we are not using durable function instead, but issue seem not related.

Issue is only one pod is picking up all the triggers, other pods remain idle.

Have put LeaseCollectionPrefix, same for all pods.

Any idea why other pods are not picking up triggers when first pod is in wait with polly?

Answer 1

Hi Jithin KV,

Greetings! Thanks for posting question in Microsoft Q&A Portal.

Thanks for sharing details. Here,

In a Cosmos DB-triggered Azure Function, change feed partitions are assigned using a lease system. Each function instance grabs leases from a dedicated lease container to claim responsibility for specific partitions.

Under normal circumstances, the instance holding a lease keeps renewing it frequently, which prevents other instances from seeing it as available or expired. As a result, those other instances never try to take over the lease.

However, in your case, the Polly retry logic introduces long-running executions. This delay causes the function host to get stuck processing a single item, during which it continues to hold onto the lease but cannot effectively manage or rotate it.

This behavior leads to a situation where one pod ends up handling all the partitions, while other pods remain idle, simply because the leases are never released or reassigned.

You want to review or update host.json settings for your Azure Function app especially to tweak Cosmos DB trigger behavior (like lease management), so scaling works better and multiple pods can process changes more effectively.

Steps to follow:

1.In the Azure portal, navigate to your Function App’s Configuration page.

2.Under “Application settings,” locate or create an entry for host.json.

• Under the “Application settings” tab, look through the list of key-value pairs.
• Usually, you won't see host.json listed here because it's a file, not a setting.
• But you can upload or mount a host.json file if you're using advanced setups (like containerized apps in AKS).
• If you're using containers, the host.json is baked into the image, so you would update it there.

3.Edit the JSON to include tuned lease-management settings under the Cosmos DB extension.

• Below is a host.json sample with tuned lease parameters. You may need to adjust intervals based on your processing time and desired steal aggressiveness

{

"version": "2.0",

"extensions": {

"cosmosDB": {

  "leaseOptions": {

    "leaseRenewInterval": "6s",

    "leaseAcquireInterval": "3s",

    "leaseExpirationInterval": "20s",

    "maxItemsPerInvocation": 100

  }

}

This tells the function how often to renew leases, how long leases last, and how many items to process per function call helping distribute work better.

4.After updating the host.Json, go to your AKS cluster in Azure.

• Find your deployment or pod list and delete all the running pods.
• Kubernetes will automatically create new pods, and these new ones will read the updated host.json when they start up

The Azure Portal doesn’t allow editing host.json directly unless you're using App Service plan + editing from Advanced Tools (Kudu).

If you're not using containerized Functions, you'd normally update host.json through deployment (VS Code, Azure CLI, GitHub Actions, etc.)

If you have any further questions, please feel free to post here. I am Happy to assist you!