-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support json as a dataType for queueTrigger #4207
Comments
@TylerLeonhardt - I think this should be behavior controlled by the language worker instead of the host? Ex: https://github.com/Azure/azure-functions-nodejs-worker/blob/b678aea76bfcba3ae082558d67e07745e29d5176/src/Converters.ts#L43 |
@TylerLeonhardt - As @mhoeger mentioned, host sends trigger input data as string/json Language worker needs to control how it is presented to the function code on invocation. Closing this as for now. Please reopen if you still think we need to address this. |
Sorry for the delay! Not sure how I missed this. @mhoeger I see from the snippet that the node worker treats string/json as the same and attempts to parse it regardless (even if the TypedData is a My understanding would be that the host would use the If the expectation is that the worker should try to parse |
Host should set azure-functions-host/src/WebJobs.Script/Rpc/MessageExtensions/RpcMessageConversionExtensions.cs Lines 63 to 66 in 8bd4fee
Reopening this issue to investigate. |
Thanks @pragnagopa! We have implemented what the node worker does (thanks again for that, @mhoeger!) in Azure/azure-functions-powershell-worker#186 |
A related issue: Azure/azure-functions-powershell-worker#205 @pragnagopa when fixing this issue, please be noted that for the |
I disagree with the OP in general as I personally find forced parsing of string values undesireable. Regardless of that though, as it is implemented at the moment, it generates a "System.Management.Automation.OrderedHashtable", which from a PowerShell perspective seems wrong - the builtin ConvertFrom-Json Cmdlet creates a "System.Management.Automation.PSCustomObject" if used to parse a JSON string with one object in it. PS C:\> '{"action":"a","option":"b"}' | ConvertFrom-Json
action option
------ ------
a b PS C:\> '{"action":"a","option":"b"}' | ConvertFrom-Json | Get-Member
TypeName: System.Management.Automation.PSCustomObject
Name MemberType Definition
---- ---------- ----------
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
action NoteProperty string action=a
option NoteProperty string option=b So, if the trigger absolutely needs to parse an input JSON string, it should in my opinion mirror PowerShell's normal behavior and create a PSCustomObject, not convert into a Hashtable. |
Repro steps
{"hello":"World"}
Expected behavior
Function receives the json as a json object so it can be properly turned into a hashtable for PowerShell Function users
Actual behavior
Function receives the json as a string and it gets passed in as a string.
Known workarounds
Related information
powershell
queueTrigger
The text was updated successfully, but these errors were encountered: