CODEWITHSUNDEEP
azureazure-functionsazure-cosmosdb
stinaq
stinaq

Reputation: 1284

Azure function takes a really long time to trigger

We have an Azure function v3 running Node, consumption plan, with an input trigger connected to a cosmos database. The function.json looks like this:

{
"disabled": false,
  "bindings": [
    {
      "type": "cosmosDBTrigger",
      "name": "productDocuments",
      "collectionName": "products",
      "direction": "in",
      "connectionStringSetting": "DB_CONNECTION_STRING",
      "databaseName": "product-management",
      "createLeaseCollectionIfNotExists": true,
      "maxItemsPerInvocation": 1
    },
    {
      "name": "productDocument",
      "type": "cosmosDB",
      "databaseName": "product-management",
      "collectionName": "products",
      "createIfNotExists": true,
      "connectionStringSetting": "_DB_CONNECTION_STRING",
      "direction": "out"
    }
  ],
  "scriptFile": "dist/nameOfFunction.js"
}

But this trigger is working really, really slow and unreliable. If we add an item to the DB it sometimes triggers straight away, sometimes it seems to take hours and sometimes not at all. I am manually monitoring the cosmos db so I can see that items are added.

I am looking at this page, and most of the time nothing happens. I don't know how else to debug this monitor page

Should it really take hours for an invocation to show up here? Or is it the trigger that's unreliable?

Upvotes: 0

Views: 1448

Answers (2)

stinaq
stinaq

Reputation: 1284

Our problem with this was that we had two separate functions that both had a CosmosDBTrigger on the same collectionm but used the same lease, and apparently you can't do that. So it was solved by setting two separate leases (we used the leaseCollectionPrefix in the function.json.)

Upvotes: 0

Matias Quaranta
Matias Quaranta

Reputation: 15583

General guidance is in this doc: https://learn.microsoft.com/azure/cosmos-db/troubleshoot-changefeed-functions#my-changes-take-too-long-to-be-received

What happens on Consumption Plan is that, after a period of inactivity, instances are deprovisioned. When a new instance is provisioned, it hits a cold start.

The key part here is that, when your instances are deprovisioned, they are not checking the Change Feed for events, so how does Functions know when to "wake them up"?

There is a periodic check done by an external component that checks to see if there are new changes, if there are new, then it would provision new instances of your Function to start consuming them.

This external component in your case, could be having an issue or delays in this checks.

If you have no Function logs for an hour even though you are making changes to the monitored collection, I would try to contact Azure Support to understand why is your Function not "waking up".

One of the known issues I've heard about was related to where the Cosmos DB Connection Strings were stored. Apparently this component at some point (maybe it's already fixed) had a problem where it could not access the Connection String if it was saved in "Connection Strings" section of the Function configuration, but was looking for it only on the "App Settings". In this cases, it could not wake up the Function and the Function only woke up if someone opened it on the Azure Portal. My recommendation would be to check where are you storing your connection string and see if you can move it to "App Settings" and see how it behaves.

Upvotes: 3

Related Questions