Fix out-of-sync binding names causing null ref error #216
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #210
The logs from the user indicate a mismatch in the binding name between the host and worker ("httpTrigger17" vs "httpTrigger19"). I suspect our logic in "addBindingName" isn't reliable enough at returning the same binding name. When I first adjusted the logic in "addBindingName" (see the original issue) I thought the problem only repro-ed with multiple workers in parallel, but now I think it can also happen with multiple workers in serial (aka a worker restarts, but the host stays the same). Fwiw, I checked telemetry and only a handful of apps are hitting this issue, but I definitely don't want anyone to hit this at all.
Anyways, my new solution is to create a hash of the binding configuration, which should reliably create the same binding name each time and also be unique within the function (we need name uniqueness at the function level, but not the app level). The only way we could get conflicting names is if they register bindings with the exact same config within a single function, but I have no idea why someone would do that. Regardless, I added an error up front so that it will fail-fast if they're in that situation and be easy for them to fix.
Lastly, I split this PR into two commits for easier review: