NodeJS host.json file when invalid works locally but not when deployed

[abjfdi]

Since the azure functions core tools is trying to emulate Azure Functions I consider this a bug or an enhancement.

I created a function that used bindings for table storage, read & write and used http triggers for this. My host.json file was invalid and everything worked locally when it should not work locally.

I spent hours debugging this by deleting code, hardcoding variables etc to finally find out my host.json was invalid. The azure Functions App wasn't helpful when debugging this because it kept only showing a HTTP 404.

I had this in the host.json file:

"extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[1.*, 2.0.0]"
}

When it should have been this:

"extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[1.*, 2.0.0)"
}

I'm not sure how hard this would be to emulate correctly, but maybe a JSON Schema checker could do the trick.

[anthonychu]

I think technically both of those are valid version ranges. The problem appears to be how they resolve in the cloud vs locally.

@soninaren Do you know what might be happening here?

[anthonychu]

I should clarify though that the latter example that ends in ) is the intended value. Not sure if there’s a way to flag the first example using a schema validation as a warning and not an error.

[abjfdi]

Honestly I would think most developers would want an error here rather than a warning, because you get an error in the cloud. But that's my opinion.

[soninaren]

Since the azure functions core tools is trying to emulate Azure Functions I consider this a bug or an enhancement.

I created a function that used bindings for table storage, read & write and used http triggers for this. My host.json file was invalid and everything worked locally when it should not work locally.

I spent hours debugging this by deleting code, hardcoding variables etc to finally find out my host.json was invalid. The azure Functions App wasn't helpful when debugging this because it kept only showing a HTTP 404.

I had this in the host.json file:

"extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[1.*, 2.0.0]"
}

When it should have been this:

"extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[1.*, 2.0.0)"
}

I'm not sure how hard this would be to emulate correctly, but maybe a JSON Schema checker could do the trick.

What @anthonychu mentioned is correct, this is a valid version range and locally it tried to find the highest version from the resolved version range from the cdn and download it. However on azure it would first try and find highest matching version of bundle available on the cloud worker, since 2.0.0 is not present on the cloud worker it would resolve it to highest version of 1.x because on cloud it attempts to avoid unnecessary downloads.

The issue here is trying to identify the intent of the user, we can provide a warning in core tools when the bundle version range includes more than one major version, since that would lead to unexpected results like above.

[anthonychu]

Good idea @soninaren. /cc @apawast @michaelpeng36