7

TL;DR: This example is not working for me in VS2017.

I have an Azure Cosmos DB and want to fire some logic when something adds or updates there. For that, CosmosDBTrigger should be great.

Tutorial demonstrates creating trigger in Azure Portal and it works for me. However, doing just the same thing in Visual Studio (15.5.4, latest by now) does not.

I use the default Azure Functions template, predefined Cosmos DB trigger and nearly default code:

[FunctionName("TestTrigger")]
public static void Run(    
    [CosmosDBTrigger("Database", "Collection", ConnectionStringSetting = "myCosmosDB")]
    IReadOnlyList<Document> input,
    TraceWriter log)
    {
        log.Info("Documents modified " + input.Count);
        log.Info("First document Id " + input[0].Id);
    }

App runs without errors but nothing happens when I actually do stuff in the database. So I cannot debug things and actually implement some required logic.

Connection string is specified in the local.settings.json and is considered. If I deliberately foul it, trigger spits runtime errors.

It all looks like the connection string is to a wrong database. But it is exactly the one, copypasted, string I have in the trigger made via Azure Portal.

Where could I go wrong? What else can I check?

psfinaki
  • 1,814
  • 15
  • 29
  • 2
    Could it be you are running both portal and local at the same time for the same collection? – Mikhail Shilkov Jan 19 '18 at 13:44
  • Yes, I did not disable or delete functions I created in the portal before switching to VS. Now that I deleted those in the portal, locally things work. – psfinaki Jan 19 '18 at 13:56
  • Thank you, Mikhail! But... what the hell? – psfinaki Jan 19 '18 at 13:57
  • 1
    The Cosmos DB Trigger internally uses the [Change Feed Processor Library](https://learn.microsoft.com/en-us/azure/cosmos-db/change-feed#using-the-change-feed-processor-library). Leases for each Partition Key Range are generated and Function instances will claim these leases and process the Partition Key Ranges. If you have more than one Function listening to the same collection while using the same lease collection, only one of them will actually acquire the leases. – Matias Quaranta Jan 19 '18 at 14:09
  • @MatiasQuaranta BTW, what should be the Partion Key. I was looking into some example and I choose a default of PartionId. For me, I pre created the Lease collection. Not sure if this is where I am making the mistake. – Shamim Hafiz - MSFT Mar 03 '19 at 07:50
  • You can let the Trigger create the leases collection for you, with the `CreateLeaseCollectionIfNotExists` attribute or create it yourself. The lease collection can be non-partitioned, or partitioned (with /id as Partition Key). – Matias Quaranta Mar 04 '19 at 16:15

1 Answers1

10

Based on your comment, you were running both portal and local Apps at the same time for the same collection and the same lease collection.

That means both Apps were competing to each other for locks (leases) on collection processing. The portal App won in your case, took the lease, so the local App was sitting doing nothing.

Mikhail Shilkov
  • 34,128
  • 3
  • 68
  • 107
  • 1
    Hello Mikhail; do you have some more info on `leases` and why are they needed ? – Stef Heyenrath Oct 05 '18 at 06:09
  • TL DR: The leases collection is used to store state, basically, at which point in time on the Change Feed is the Function on. In case of a Function host restart or anything that might turn it off and on, the leases allow for the Function to pick up where it left off, it also allows scaling (multiple Functions instances) to work. More info here: https://learn.microsoft.com/azure/cosmos-db/change-feed-processor#implementing-the-change-feed-processor-library – Matias Quaranta Mar 04 '19 at 16:17
  • 1
    Ran into this issue and needed to delete the entries in the lease container so that my local instance could obtain the lease – Stephen McDowell Sep 28 '20 at 15:24