Error on CosmosDBTrigger in Function when collection is modified

[robece]

Error when DocumentDB collection is modified and CosmosDBTrigger is fired.

Repro steps

Step 1- Create a Azure Function project then a new function, then install nuget package: Microsoft.Azure.WebJobs.Extensions.DocumentDB.

[FunctionName(nameof(DocumentCleaner))]
    public static void Run(
        [CosmosDBTrigger("Database", "Collection", ConnectionStringSetting = "PersonTrigger_ConnectionString")]IReadOnlyList<Document> input, TraceWriter log)
    {
        log.Verbose("Document count " + input.Count);
    }

Expected behavior

• Function should be starting when a change is detected in the collection.

Actual behavior

An error is raised without any reason when the collection is modified:

Exception while executing function: DocumentCleaner. Microsoft.Azure.WebJobs.Host: Exception binding parameter 'input'. Microsoft.Azure.WebJobs.Extensions.DocumentDB: Binding can only be done with IReadOnlyList or JArray.

Known workarounds

No workaround detected.

Related information

Microsoft.Azure.WebJobs.Extensions.DocumentDB - 1.1.0-beta4

[paulbatum]

@ealsur Any ideas on this one?

[ealsur]

@rcervantes Are you by any chance redefining the Document class? That exception is thrown if the type of the binding is not IReadOnlyList<Document> or JArray, and the Document is a Microsoft.Azure.Documents.Document.

[msimpsonnz]

Had the same error, was related to using latest version of Microsoft.Azure.Documents, downgraded to 1.13.2 and fixed https://social.msdn.microsoft.com/Forums/en-US/b1d372d5-ea24-4a61-8d3b-af459e3a26ff/azure-function-tracking-cosmosdb-fails-to-capture-the-documents?forum=AzureFunctions

[VisualBean]

i am still having this issue in 1.21.1

[ealsur]

@VisualBean as stated in the previous comment, use the default SDK version that comes with the Functions packages (SDK 1.13.2).

[jefflafay]

I don't have Document redefined anywhere and I experience this bug with 1.21.1 and 1.22.0. Is there any work towards fixing the bug because new versions are coming out that don't have the fix.

[ealsur]

@jefflafay The solution is the one I sent in my previous comment. Due to a dependency lock that Azure Functions runtime has, you need to downgrade to 1.13.2 or remove the DocumentDB SDK package dependency (it will get solved by the Extensions.DocumentDB package).

[jefflafay]

@ealsur I removed it from my nuget packages and replaced it with the Extensions.DocumentDB package. Thanks for the clarification.

[m1nkeh]

hi, when will this get fixed pleased, the latest Microsoft.Azure.DocumentDb version that works is 1.13.4 which is over a year 'out of date'...

[ealsur]

@m1nkeh The SDK version is being bumped on Functions V2 through this PR https://github.com/Azure/azure-webjobs-sdk-extensions/pull/410

I don't know for V1 if there is any plan on updating or if Functions will support binding redirects.

[m1nkeh]

ok, thanks @ealsur .. do you know if you can get an official line on that? We could look at migrating our code to v2... this is a brand new project, not in production yet... should we have used v2 from the start?

[paulbatum]

@m1nkeh At this point we do not intend to update the version of Microsoft.Azure.DocumentDb included in V1. For V2 we have changed our design so that we can safely update our dependencies without concern about regressing production Function Apps. For your new project it is hard to provide an official recommendation but I'll give you this general guidance - unless your project needs to go into production within the next 3-4 months, I would target V2.

[m1nkeh]

oh right... @paulbatum we are looking to go-live next month, this is a bit of an issue. what we will do is split out the projects in to two so that they can ref different versions of the SDK ... not ideal, but it seems like the only option right now. not very cool that it has come to this though!

[ronmichael]

FWIW I was able to use Microsoft.Azure.DocumentDB 1.22 if I used JArray as the function parameter type AND installed Newtonsoft.Json 9.0.1 rather than 10 or 11. (which meant also downgrading Azure.Storage to a version that allowed Newtonsoft < 10.) What a mess.

[m1nkeh]

what a mess indeed... we have ours working, and i'm not touch it at this point.. feels a bit like a house of cards that is very finely poised.

I'm sure you had just as much fun making it work @ronmichael 👍