recursive camelcase binding data about azure-functions-nodejs-worker HOT 5 CLOSED

@mamaso if you're still checking - can you provide details :) i think you mean camelcasing binding data from the functions host side (Azure/azure-functions-host#2571), and making sure it is done recursively.

from azure-functions-nodejs-worker.

Yep, the issue is well summarized in Azure/azure-functions-host#2571

I added it here because I thought it made more sense to handle this in the language worker (as it's node specific behavior), rather than special casing it in the host.

One alternate possibility would be to have the camel case handled by the host if there are other languages which would like binding data in camel case form. A language worker describes to the host if it would like camel case or not in the json configuration that Chris whipped up.

from azure-functions-nodejs-worker.

You're the best Matt!! It'd be super nice to have formatting as a part of the language worker contract, but I lean towards your original suggestion of having binding data formatted by each language worker for cases like Python's lowercase_underscores (and for whatever other future languages we support). Thanks again!

from azure-functions-nodejs-worker.

Note: requires corresponding test change in azure-functions-host repo (Azure/azure-functions-host#2571)

from azure-functions-nodejs-worker.

Updated details: the bug was that the keys in context.bindingData were camelCased one layer down but no further.

Before Fix:
context.bindingData.sys.MethodName would be HttpTriggerJS1

After Fix:
context.bindingData.sys.methodName would be HttpTriggerJS1

from azure-functions-nodejs-worker.