Open JR-Morgan opened 1 month ago
Hi, the problem is that the payload field is not always there in the websocket protocol. What's in there can only be decided after the first deserialization and evaluating the type field.
The easiest way to solve your problem you would be to implement your own NewtonsoftJsonSerializer, which uses a different instance of json serializer settings for DeserializeToWebsocketResponseWrapperAsync
, which is where your exception is thrown and which is the "partial" serialization step needed to get the type field from the message.
I'd be glad to incorporate that "separation" of serializer settings into the library if you submit that as a PR.
Amazing, thanks. I'm already using a fork of the NewtonsoftJsonSerializer
so tweaking it is quite easy for me.
I've just tested with making the DeserializeToWebsocketResponseWrapperAsync
always use the DefaultJsonSerializerSettings
, as this was simplest, and I don't see any valid reason users would ever want to customise this JsonSerializerSetting
since its only used for deserializing WebsocketMessageWrapper
s.
This is now working great for me 😁
Would you like this as a PR?
Yea please do a PR. I think this should have been there from the start...
My goal is to be able to utilise the
MissingMemberHandling.Error
option of theJsonSerializerSettings
, instead of the defaultMissingMemberHandling.Ignore
.Why? because its a very useful way to ensure that the classes I'm crafting as deserialization targets for my queries actually match the queries being sent. It makes it impossible to accidently query for something that will be ignored during serialization, as this will throw a
JsonSerializationException
This works perfectly for regular queries and mutations. But not for subscriptions or
UseWebSocketForQueriesAndMutations = true
Instead, I get this exception thrown deep from
ReceiveWebsocketMessagesAsync
I've captured the offending response from the server. And it does indeed have a
payload
property, (the value of which is all from my GraphQL api)But poking around a little, this seems like an indented outcome seeing as
WebsocketMessageWrapper
does not need to store thepayload
I was wondering if this was intentional, as it's preventing me from using this serializer setting for my entire SDK.