Azure / Azure/azure-functions-host
Unsupported Storage Emulator reports confusing error message
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 38
Description
#### Investigative information
Please provide the following:
- Timestamp: 1/21/2018 4:24:54 PM
- Function App version (1.0 or 2.0-beta): 2.0-beta
- Function App name: LocalQueuesForRemoteEventHubs
- Function name(s) (as appropriate): QueueEntryPoint
- Invocation ID: n/a (local)
- Region: n/a (local)
#### Repro steps
Provide the steps required to reproduce the problem:
- Have Storage Emulator 5.1 installed locally and forget to start it before running your function.
- Create a function: `func new --language C# --template QueueTrigger --name QueueEntryPoint`
- Manually set configs in local.settings.json for AzureWebJobsStorage and AzureWebJobsDashboard to "UseDevelopmentStorage=true"
- `func start`
- receive following error which is reasonably correct (and can be found online with some searching):
> ...
> Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.QueueEntryPoint'. Microsoft.Azure.WebJobs.Host: Invalid storage account 'devstoreaccount1'. Please make sure your credentials are correct.
> ...
- Ctrl+C function
- Start Storage Emulator
- `func start`
- receive same exact error as above
#### Expected behavior
I would expect (at a minimum) a different error message for the two cases. In the first, it cannot find the service, in the second I think it is calling the API with an unsupported API version string.
#### Actual behavior
The error messages are exactly the same for both situations, leaving you with a black box situation to debug. The first attempted fix (starting the storage emulator) actually fixes the initial error, but because the message is exactly the same the second time the immediate reaction is "maybe the storage emulator start failed, let me go debug that". Luckily I have a lot of experience with storage API changes and the Storage Emulator, so I moved past that stage and realized it might be an API version mismatch or something similar and updated the Emulator. I could see someone less experienced losing some significant time/momentum to this.
The Storage API returns a specific error for a version mismatch (400 Bad Request, `InvalidHeaderValue` [storage api error](https://docs.microsoft.com/en-us/rest/api/storageservices/common-rest-api-error-codes), with `x-ms-version` identified in the error result) that can be easily differentiated from an unable to connect error. I haven't confirmed this was exactly the issue causing it to fail, but consider it to be a high probability without looking into the code to see what version the SDK was expecting.
#### Known workarounds
Guess and upgrade Storage Emulator.
#### Related information
Example Storage API Error (using a made up version to force it):
StatusCode: `BadRequest`
StatusDescription: `The value for one of the HTTP headers is not in the correct format.`
Body:
```
InvalidHeaderValueThe value for one of the HTTP headers is not in the correct format.
RequestId:92ccdc18-b1ef-431f-a65b-980f1aa433ca
Time:2018-01-21T17:04:08.8251550Zx-ms-version2015-12-12
```
Contributor guide
Research direction
Reproduce the issue with QueueEntryPoint, local.settings.json, `func start`, and Storage Emulator 5.1, comparing the stopped-emulator and started-emulator cases. Trace the host's storage initialization and error handling to identify where connection failures and the reported `InvalidHeaderValue` response become identical; done means the two failures produce distinguishable messages.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp
- Domain
- backend, cloud
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100