HttpTrigger not populating binding data from query

Using v1, I have a function app that uses a route on the HTTP trigger and an id parameter for a CosmosDB input binding.

Here is the function.json for that function:

 "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "route": "document/{documentId}"
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "type": "documentDB",
      "name": "document",
      "databaseName": "CookieBinge",
      "collectionName": "Binges",
      "connection": "datapointscosmosdb_DOCUMENTDB",
      "direction": "in",
      "id": "{documentId}"
    }
  ],
  "disabled": false
}

My app outputs one of the values from the incoming document. This app is written in C#. I can use the test feature to pass in a document id and it runs successfully.

I’m building a new function using v2. The binding uses v2 settings.

{
  "type": "cosmosDB",
  "name": "document",
  "databaseName": "Ninjas",
  "collectionName": "Ninjas",
  "connectionStringSetting": "datapointscosmosdb",
  "direction": "in",
   "id": "{documentId}"
}

It fails with internal server errors if I try to test on the portal. error: One or more errors occurred. (Worker process with pid 6236 exited with code 1) (Worker process with pid 4316 exited with code 1) (Worker process with pid 4728 exited with code 1) When debugging in VS Code using the extension, the incoming bound document is not a single document but it is all of the docs in the collection. I can see the documentId value in the context.bindingData. I’ve been banging on this problem for a while and thought that maybe I’ve just hit a bug and it’s not me. 😃

Investigative information

Please provide the following:

• Timestamp: ??? Don’t know how to see this from context in vs code
• Function App version (1.0 or 2.0-beta): 2.0-beta
• Function App name: NinjaFunctions2
• Function name(s) (as appropriate):
• Invocation ID: “1273ffff-ac34-4e99-a2b3-f82b4b6a0194”
• Region:

[brettsam]

Agree. We’ll need to fix it.

For a little background – SqlQuery (and Table’s query) has custom logic for preparing the query payload (https://github.com/Azure/azure-webjobs-sdk-extensions/blob/dev/src/WebJobs.Extensions.CosmosDB/CosmosDBSqlResolutionPolicy.cs), and it wasn’t designed for nested properties. The context we’re given doesn’t have enough information for us to build up the SQL query in the way we need to.

[fabiocav]

That’s correct. This is a V2 regression that must be addressed. I think this can be done this sprint, so I’m updating the milestone.