Azure-webjobs-sdk: consider adding TypeNameHandling.All to the Json serialization settings

Created on 3 Jun 2016  路  6Comments  路  Source: Azure/azure-webjobs-sdk

I have a WebJob triggering from a queue message and the message argument is set as an abstract base type.
As a result I get an exception saying that I could use a string and handle the serialization myself.

If the serialization settings for both serialize and deserialize had the TypeNameHandling set to All, then I believe the derived objects would be serialized correctly:
new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.All }

Thank you,
Paulo

help wanted improvement

Most helpful comment

We could probably expose a hook for the serializer settings to be changed.

All 6 comments

Could you share a quick repro? This would help us narrow down the issue and properly triage.

I don't have an isolated repro at hand although I can certainly create one, but I did take a look at the code and found a unit test that that for a UserType in a QueueTrigger so I added another test that used a DerivedUserType in a Queue trigger:
https://github.com/papinto/azure-webjobs-sdk/commit/2c9f15540244c0b366b612bf1dfebadec70b7f57

If you remove the TypeNameHandling.All from the JsonSettings (either on the serialization side or deserialization), the new unit test fails with:

Microsoft.Azure.WebJobs.Host.UnitTests.Queues.QueueTriggerBindingIntegrationTests.BindAsync_IfDerivedUserDataType_ReturnsValidBindingData(userPropertyName: "IsDerived", userPropertyValue: "True") [FAIL] Assert.True() Failure Expected: True Actual: False

I also had to make a couple changes to the BindingDataProvider so that it accepts a derived type and returns the correct binding data.
I haven't run any other tests and I'm not familiar enough with the code to suggest that this should be the implementation for it (in fact I don't like the way I had to bypass the _propertyHelpers in that change - I just wanted to see if I could get it to work).
Hopefully the unit test shows the intention of the issue I ran into.

If you still think a repro would be good, I can set one up but not for another couple of weeks.

Thanks for looking into this.

We could probably expose a hook for the serializer settings to be changed.

@papinto, have you found a work around for this issue until a hook is exposed for the serializer settings?

@HMoen I haven't looked at this in a while but I think the only way to get around it is to create several messages for the different derived types (instead of a single one for the base type).

@papinto, thanks. We used a direct implementation where we could set the serializer settings instead of the queue binding.

Was this page helpful?
0 / 5 - 0 ratings