-
-
Notifications
You must be signed in to change notification settings - Fork 391
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
UseNewtonsoft + clientless pattern, default serializer incorrectly used to serialize request body #783
Comments
I see you're using 4.0. Newtonsoft was removed so JObject is no longer supported. Neither are dynamics. Try the just-released Flurl.Http.Newtonsoft companion lib. I'm in the middle of documentation updates now, but here's the quick & dirty of how to use:
If you're already well versed in #770 (most people probably aren't), |
Thanks Todd - this isn't just a case of STJ vs NewtonSoft. This behaviour is observed even if you are using Newtonsoft. There is something about the serialization in the PostJsonAsync that differs from doing it outside as per my workaround above. I am already using FlurlHttp.Clients.UseNewtonsoft() TLDR; UseNewtonSoft does not fix the observed behaviour. For reference - per the original report using 4pre6. |
I can't repro this.
Yes, I get that by default.
When I swap out the default serializer for the one defined in Flurl.Http.Newtonsoft, I get exactly that. How exactly are you determining what Flurl's internals are doing when you reached your conclusions? |
In the client, I specified the usenewtonsoft method - travelling so can't give the exact details - but if you can't repro it is probably something not working like i expected so I will do some more research my end and get back - feel free to close it for now and I will hit it again if there is an issue. |
I won't keep it open forever, but I'll keep it open a bit longer if you think you'll look at it again soon-ish. ;) All the symptoms do seem to suggest STJ is still driving the serialization, even when you think Newtonsoft is in control. I suspect it's something with how you have things wired up. |
Same here:
Receives:
|
What happens if you do this:
I have run into empty results due to threading and serializer exceptions. The above would help diagnose. |
{"message":"Post received. Thanks!"} test with RoslynPad 19.1 and .net 8.0.100, no exception throws. |
Sorry for the delay, this is a priority and I'll look into it as soon as I have some time. In the mean time, you could try using the serializer directly to help determine if it's a problem with that vs the registration shortcuts. It's pretty straightforward: |
Confirmed. Sorry all, better tests would have prevented this little embarrassment. In short, "global" settings as a stand-alone thing were eliminated in 4.0 but moved to a global cache of clients used just for the clientless pattern. But with that pattern, request serialization happens before a client is selected, so changing the default serializer isn't properly applying to request bodies. (It is applying to JSON responses.) I have it proven in a test and will try to get fix released in short order. |
Who is this "ghost" who keeps deleting my comments? Am I being a bad person or something? |
@astrohart This issue is bug report, not a discussion of the merits of Newtonsoft vs STJ. I've deleted several of your comments recently because they're off-topic noise. Please stop. |
First of all let me apologize if I've been disrespectful. That was never my intent although I admit I was blowing off some steam. But there was some frustration there given I'm a contributor on a repo that uses Flurl and I had to do hours of work to use a workaround. But it was my intention to say "me too" on this bug, until I found the workaround. No hard feelings? |
Fixed & released. The core issue was in Flurl.Http; it would have been virtually impossible to fix in Flurl.Http.Newtonsoft alone. Both packages are updated (4.0.1 and 0.9.1 respectively), please update either of them and report back here if it does not resolve the issue. Sorry again for such a blatant bug! |
Thank you @tmenier! You're wonderful! |
This might be related. I try to set global default setting in
but it seem to have no effect. Null fields are still serialized when calling:
Versions
|
@amzhang Could you open a new issue for this? Comments in closed issues don't stay on my radar, and I suspect this isn't directly related anyway. |
Using a complex JSON object - something like the following, the object is incorrectly serialized by PostJsonAsync whether using STJ or Json.Net. However, when serialized outside PostJsonAsync using default settings for Json.Net, the result is as expected.
Using latest 4pre6.
E.g this doesn't work:
However, this does:
The latter correctly sends the serialized string as
{"pageToke":"","lotIntKey":11,"module":2,"lotData":{"Details":null,"Custom":null,"LinkItems":{"0":{"Int_Key":0,"Int_Box":1111,"Int_Link":2222}},"Security":null,"BIMLinks":null}}
The first one mangles the content of linkitems into some strange set of [[[],[],[]][[]]] etc.
The text was updated successfully, but these errors were encountered: