Microsoft.Azure.WebJobs.Extensions.CosmosDB incompatible with Microsoft.Azure.DocumentDB.Core 2.0.0-preview2 and 2.0.0

[kenturley]

In upgrading to latest Functions runtime, Microsoft.NET.Sdk.Functions (1.0.19), to stay in line with your recent "Runtime 2.0 preview breaking changes" announcement, I've encountered an incompatibility with one of my functions that is bound to a Cosmos DB trigger. I was able to distill the issue down as follows:

Investigative information

• Azure Functions Core Tools (2.0.1-beta.38)
• Function Runtime Version: 2.0.12050.0
• Invocation ID: This can be reproduced locally

Repro steps

1. In Visual Studio 2017 Create a new project -> Azure Functions. Choose Cosmos DB Trigger. Use "Storage Emulator" and connection string, database and collection as expected.
2. This will install the following dependencies:
   2.1 (NuGet) Microsoft.Azure.WebJobs.Extensions.CosmosDB (3.0.1-beta1)
   2.2 (NuGet) Microsoft.NET.Sdk.Functions (1.0.19)
   2.3 (SDK) NETStandard.Library (2.0.3)
3. F5 run the application. It runs, will fire when a document is added to the specified collection, etc.
4. Now install NuGet Package Microsoft.Azure.DocumentDB.Core (Latest stable 2.0.0)
5. F5 Run your application. You should receive the following "method not found" exception, which is the issue I'm reporting that has interrupted our development process:
   [9/9/2018 6:52:50 PM] Found the following functions: [9/9/2018 6:52:50 PM] CosmosTrigger.Function1.Run [9/9/2018 6:52:50 PM] [9/9/2018 6:52:50 PM] Host initialized (356ms) [9/9/2018 6:52:53 PM] The listener for function 'Function1' was unable to start. [9/9/2018 6:52:53 PM] The listener for function 'Function1' was unable to start. Microsoft.Azure.Documents.ChangeFeedProcessor: Method not found: 'System.Threading.Tasks.Task1<Microsoft.Azure.Documents.Client.ResourceResponse1<Microsoft.Azure.Documents.Document>> Microsoft.Azure.Documents.Client.DocumentClient.ReadDocumentAsync(System.Uri, Microsoft.Azure.Documents.Client.RequestOptions)'.
6. Use NuGet to downgrade to DocumentDB.Core to (2.0.0-preview2). Run the app. Same exception.
7. Use NuGet to downgrade to DocumentDB.Core to (2.0.0-preview) --note no "2" just "preview." It will now run.

Expected Behavior

We are running a function app in production. We have it pinned at runtime 2.0.11961-alpha which will expire soon. I am trying to migrate to latest packages/versions in order to stay current. I need to access my Cosmos DB out of my Function App trigger that binds to Cosmos DB. That is why I need both NuGet packages and expect them to be compatible.

Workarounds

It appears I can run with DocumentDB.Core to (2.0.0-preview) installed (2 versions behind latest stable 2.0.0) until this issue is resolved. Hopefully this version will remain compatible with future Function App runtimes as older ones are deprecated.

Follow Up

I published to Azure with the workaround in place: using DocumentDB.Core to (2.0.0-preview). The trigger will not fire on Cosmos DB Collection change.

I simplified and removed DocumentDB.Core completely. I can run the function locally out of Visual Studio and it triggers perfectly off of Cosmos collection changes. I published this simple version to Azure and it will not fire off DB changes.

The simplified, published version is in function app KWTCosmoTest, Central US, CentralUSPlan (Consumption). The function is the only one in there, named Function1 straight out of VS 2017 New Project template.

Final note: We have an Azure Function bound to our Cosmos DB running in production. Has been for 3+ months and works fine. So I know my code is good and these things work. But it is pinned to 2.0.11961-alpha because it is running older 1.0.13 version of Microsoft.NET.Sdk.Functions and that pinned runtime, according to your documentation, is going away at end of Sept. So we have to get this sorted out by then,

Conclusion

Please let me know my best course of action and/or when this incompatibility between packages will be resolved. Thank you.

[brettsam]

We have not built an extension against DocumentDB.Core 2.0.0 yet so you're likely running into some major-version-mismatch issues.

If you move to https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.CosmosDB/3.0.1-beta2 and keep DocumentDB.Core on 1.9.1, do things work?

[brettsam]

@ealsur as FYI.

[ealsur]

This is an incompatibility with the SDK 2.0.0-preview2 since it contains some API changes it seems, it's been tracked by Azure/azure-documentdb-changefeedprocessor-dotnet#96

[kenturley]

@brettsam It looks like that combination, 3.0.1-beta-2 with DocumentDB.Core on 1.9.1 and Microsoft.NET.Sdk.Functions 1.0.19 builds and runs without conflict. So that solves my one problem. HOWEVER, the function will still not trigger off Cosmos DB change. I verified again using the simple KWTCosmoTest function app (referenced in my original post) that is generated straight out of VS 2017 Template.

So that's still an issue for me --are function trigger bindings to Cosmos working in the new runtime?

[brettsam]

Yes, they should be working. Are you sure that no other functions are watching for changes to that Collection?

One way to test it is to swap the local connection string to use the local CosmosDB emulator -- that way you know no one else is watching for changes.

[ealsur]

@kenturley Please check if there are no errors in the console when the local Functions runtime starts.

Also verify if you don't have another Function listening to the same collection with the same leases collection. If you do, you can use the LeasePrefix https://medium.com/@Ealsur/azure-cosmos-db-functions-cookbook-multi-trigger-f8938673de57

[ealsur]

@brettsam We released a new package of the CFP Library that is compatible with 2.0.0 and it should solve this.

[ealsur]

@kenturley this should be fixed in the next Extensions release, the PR with the update has been merged.

[kenturley]

Sorry for being MIA last 2 weeks. Been pulled off on other project. Thank you for your posts here. I'll try the new Extension release and see if that fixes the issue.

[ealsur]

@kenturley You won't need to reference the DocumentDB SDK directly, the Extension already has the 2.0.0 package included.

[ealsur]

Closing as the issue should be resolved in the latest Extension package.