Azure-functions-host: "Value cannot be null" error when AzureWebJobsStorage is missing for output binding

Created on 29 Jul 2019  路  7Comments  路  Source: Azure/azure-functions-host

func --version
2.7.1480

Repro steps:

  1. Create a new project (language shouldn't matter, but I did JS)
  2. Add an http trigger
  3. Add a Cosmos DB output binding to that trigger
  4. Make sure extension bundle is set in host.json
  5. Make sure AzureWebJobsStorage is _not_ set in local.settings.json

Expected:

A readable error message saying AzureWebJobsStorage needs to be set. Honestly I would expect this to be the same error message that occurs if you have a Cosmos DB trigger (instead of output binding) without AzureWebJobsStorage set. That error is much better.

Actual:

Error message:

Value cannot be null.
Parameter name: provider

_originally brought up by @askpatrickw in https://github.com/microsoft/vscode-azurefunctions/issues/1403#issuecomment-515238736_

P1 Supportability error-message-improvement no-repro

Most helpful comment

@ahmelsayed yeah I'm not asking you to change the behavior of when it's required - just to print out a better error message than "Value cannot be null."

All 7 comments

Requiring storage for all output/input bindings would be a breaking change. Today it's only required if you have anything other than http or kafka triggers, but not bindings.

@fabiocav do you have a list of the input/output bindings that require AzureWebJobsStorage

@ahmelsayed yeah I'm not asking you to change the behavior of when it's required - just to print out a better error message than "Value cannot be null."

I understand, and I agree that error messages should be better.

The problem is that this error message is coming from the runtime, not the core-tools. The core-tools sets things up, then invokes the runtime. It should be the runtime's responsibility to properly handle invalid function settings, but it doesn't. It just re-throws those exceptions. Since it was too confusing for users, and apparently too complicated for the runtime to display the right errors, the core-tools parses function.json itself and maintains a list of what works with what

I can't repro this in later versions of the core tools and I'm not sure if this is actually related to the missing AzureWebJobsStorage setting.

Here is the behavior in core tools version 2.7.1480:

[6/23/2020 1:04:49 AM] Looking for extension bundle Microsoft.Azure.Functions.ExtensionBundle at C:\Users\mahoeger\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle
[6/23/2020 1:04:49 AM] Found a matching extension bundle at C:\Users\mahoeger\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.1.1
Value cannot be null.
Parameter name: provider
Application is shutting down...

Behavior in core tools version 2.7.2508:

[6/23/2020 1:03:24 AM] Looking for extension bundle Microsoft.Azure.Functions.ExtensionBundle at C:\Users\mahoeger\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle
[6/23/2020 1:03:24 AM] Found a matching extension bundle at C:\Users\mahoeger\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.1.1
[6/23/2020 1:03:24 AM] Fetching information on versions of extension bundle Microsoft.Azure.Functions.ExtensionBundle available on https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle/index.json
[6/23/2020 1:03:24 AM] Skipping bundle download since it already exists at path C:\Users\mahoeger\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.1.1
[6/23/2020 1:03:24 AM] Loading Extention bundle from C:\Users\mahoeger\AppData\Local\Temp\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle\1.1.1
[6/23/2020 1:03:24 AM] Loading startup extension 'CosmosDB'

Again, hard to know because it's a generic error message, but I think we can close this as resolved. At the very least, I am unable to repro with the repro steps given and should close this until we reproduce on the latest versions

@soninaren - I'm wondering if you might have been the one to fix this issue? it seems like the error might have been related to the bundles path

Closing as resolved in latest versions. Please re-open with updated repro steps if this happens again!!

Was this page helpful?
0 / 5 - 0 ratings