azureazure-functionsazure-cosmosdbazure-cosmosdb-changefeed

Cosmos db change feed trigger not firing after function goes to sleep


I have a function that works fine locally but is not triggered in Azure unless the function is "awake". The function just copies items from one container to another, with the primary key and id columns swapped (as an eventually-consistent secondary index). There are two functions in this app, both of which are Cosmos triggers (different source containers and lease prefixes); all my other functions are in other apps.

The function is in a Linux consumption plan, deployed via the GitHub Action Azure/functions-action@v1, which uses zipdeploy, which should be syncing triggers. There are no other functions listening on that container (local instances listen to the emulator), and this function has a unique lease prefix anyway.

If I view the function app in the portal (even just the Overview page), the function "wakes up" and processes all the Cosmos DB items just fine. If I then close the Overview page, wait ~30 minutes, and change an item in the watched container, the function does not fire. Nothing goes into the Azure Monitor logs and the corresponding item does not change in the destination container. I can wait several (10) minutes and refresh, and there is still nothing in the logs or the destination container. Then when I re-open the Overview page, the function immediately triggers, and the item in the destination container is updated pretty much immediately; the Azure Monitor logs show up 2-3 minutes later (a normal amount of lag). This behavior is 100% repeatable.

I've checked all the troubleshooting suggestions multiple times, but I don't see anything that would help.

How do I get this function to trigger without me observing it in the portal?


Solution

  • Turns out I had my connection strings wrong. I had the CosmosDb trigger connection string in ConnectionStrings when it was supposed to be in AppSettings.

    The function would actually work locally (and if it was already running in the cloud) because the bindings were looking in both places: AppSettings where it was supposed to be, and falling back to ConnectionStrings. However, when the function "slept", the Azure scale controller was only watching AppSettings, so that's why it would never wake up.