Azure-sdk-for-net: Cannot send anonymous objects using EventGridClient

[gplwhite]

Hello,

I am attempting to use the EventGridClient class to send some events to EventGrid. I was unsuccessful when it came to sending custom data in the data property of the EventGridEvent. EventGrid would just receive a null value. If I set the data property to a string value, it was received by EventGrid correctly, however using a complex object, the object was not serialized to JSON.

I've tracked the issue down to the EventGridClient initializing the Json serializer with an instance of the rather ambiguously named ReadOnlyJsonContractResolver(). The description of this class is:

JSON contract resolver that ignores read-only properties during serialization.

So currently, the EventGridClient will not serialize any custom event data that is exposed via readonly properties - ie: all properties on your custom data object have to be read/write.
This in turn rules out anonymous objects as your custom event data payload, as anonymous objects only implement readonly properties.

Currently, the workaround is to explicitly override the contract resolver:
C# eventGridClient.SerializationSettings.ContractResolver = null; // Use the default resolver

What rationale is there for initializing the JSON serializer with ReadOnlyJsonContractResolver? It doesn't seem to be the correct contract resolver to be using for one way serialization.

[antoinne85]

I've also hit a snag regarding the ReadOnlyJsonContractResolver.

In my case, I was attempting to send an event whose Data was an object with a constructor and get-only properties (e.g. public Guid AccountId {get; }).

What I discovered was that when these events went across the wire, the Data property on the EventGridEvent had any get-only properties omitted.

In researching the issue, I came across https://github.com/Azure/autorest/issues/1904 from the AutoREST project, where it was closed as _by-design_.

Is it a correct assumption that it is _by-design_ for AutoREST (which probably expects to be speaking to Azure APIs most of the time and not carrying arbitrary user objects over the wire) and not necessarily _by-design_ by the EventGridClient?

At any rate, if we could get some guidance on how you think we should proceed regarding this issue, it would be much appreciated.

If you don't see any ill-effects from using the workaround provided above, we can continue forward with that, but if you'd prefer some kind of PR for a change in behavior we'll need some guidance on what you expect that behavior should be.

[SeanFeldman]

Same here. Anonymous objects should be supported.

[galvesribeiro]

Did anyone ever get a solution for this? It is almost an year and that is critical to the product, specially if you are not using the client directly, like in EventGrid bindings for Azure Functions.

It is impressive that nobody from the product team made a fix for that yet...

[olandese]

Same problem here, it should be supported

[bobvandevijver]

I just ran into this issue, but I've found a workaround which seems to be working exactly as I would like. Just make sure to not set your object directly in the Data property, but wrap it with JObject.FromObject. This way, the properties should be converted using your object configuration, while made available for the ReadOnlyJsonContractResolver.

Example:
c# return new EventGridEvent { Id = Guid.NewGuid().ToString(), EventType = ObjectType, Topic = Topic, Subject = $"/company/{CompanyUuid.Value}/{ObjectType}", DataVersion = DataVersion, EventTime = eventTime, Data = JObject.FromObject(yourObject) };

[msftbot[bot]]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jfggdl.

---

Issue meta data

Issue content:	Hello, I am attempting to use the EventGridClient class to send some events to EventGrid. I was unsuccessful when it came to sending custom data in the data property of the EventGridEvent. EventGrid would just receive a null value. If I set the data property to a string value, it was received by EventGrid correctly, however using a complex object, the object was not serialized to JSON. I've tracked the issue down to the EventGridClient initializing the Json serializer with an instance of the rather ambiguously named ReadOnlyJsonContractResolver(). The description of this class is: JSON contract resolver that ignores read-only properties during serialization. So currently, the EventGridClient will not serialize any custom event data that is exposed via readonly properties - ie: all properties on your custom data object have to be read/write. This in turn rules out anonymous objects as your custom event data payload, as anonymous objects only implement readonly properties. Currently, the workaround is to explicitly override the contract resolver: C# eventGridClient.SerializationSettings.ContractResolver = null; // Use the default resolver What rationale is there for initializing the JSON serializer with ReadOnlyJsonContractResolver? It doesn't seem to be the correct contract resolver to be using for one way serialization.
Issue author:	gplwhite
Assignees:	-
Milestone:	-

[JoshLove-msft]

As mentioned in https://github.com/Azure/azure-sdk-for-net/issues/12244, this is fixed in the new library that is currently in beta.