Open TylerLeonhardt opened 5 years ago
@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 string
). Thanks for that! I can replicate that in the PowerShell worker... but it seems a bit confusing from a language worker's perspective.
My understanding would be that the host would use the TypedData
as json
if the data were json
and string
if it wasn't. We do this today in the powershell worker.
If the expectation is that the worker should try to parse TypedData.string
as json
, then is there any particular reason for TypedData.json
over just sending everything through TypedData.string
?
Host should set typedData.Json
if the input data is a json string.
Reopening this issue to investigate.
Thanks @pragnagopa! We have implemented what the node worker does (thanks again for that, @mhoeger!) in https://github.com/Azure/azure-functions-powershell-worker/pull/186
A related issue: https://github.com/Azure/azure-functions-powershell-worker/issues/205
@pragnagopa when fixing this issue, please be noted that for the RpcHttp.RawBody
field, it should be kept as typedData.String
even if it's a valid JSON string.
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. Examples:
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