-
Notifications
You must be signed in to change notification settings - Fork 679
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
Infinite loop in JObject #9
Comments
Oh oh - that doesn't sound good. It can't have been fun trying to figure out that issue :( When I first built Swashbuckle, I was only able to test against the API's and contracts I'm currently involved with. It's been awesome to have it out there in the wild and see how it holds up against all the different ways people are using WebApi. But, it's definitely highlighted some interesting bugs. I'm guessing the issue is occurring for any type that contains a member of the same type? For example public class Person |
Above continued ... public class Person This is something I thought I'd accounted for but clearly didn't get quite right. I'll try get to it next week or alternatively please feel free to submit a pull request? Thanks for bringing this to my attention Richie |
I had a look at the code there but I'm not sure what to do about it. It says "I see your JToken is enumerable. It can hold more JTokens". Then it parses the child object which is another JToken---hence the infinite loop. My original problem was that I was not able to figure out how to bind to the incoming json object to a strongly typed object using FromBody (see: http://blog.travisgosselin.com/web-api-signatures-with-multiple-complex-parameters/) when I wrote the WebApi call. I finally gave up and declared it a JObject and parsed the incoming data structure (which is arbitrarily deep) internally. Apart from detecting the error condition where there's a cycle of nested types, is there a way to override the api-descriptor generator so that I can provide my own description of what the posted body should be? |
Just took a look at this and you're correct - it's not going to be the easiest thing to solve. I'd have to really rethink the recursive algorithm. But it seems like a common scenario that definitely should be supported. I definitely intend on taking a deeper dive when I get some free time. For your scenario, It's probably a little pointless for Swashbuckle to generate a model spec for JObjects as the resulting description would be very "meta" and have no context of the actual operation. In fact, I think I'll special case this (as is currently done for HttpResponseMessage) to be treated as undetermined. The net effect would be no model description in the UI For your scenario, there are a couple of options you may want to investigate.
You can override the dynamic ModelSpec generation for specific types by setting a pre-canned version at config time (app start) ... SwahbuckleSpecConfig.Customize(c => You could use this to get past the infinite loop problem, but you still won't be able to differentiate between the JObject description for different operations.
SwahbuckleSpecConfig.Customize(c => The the filter implementation would look something like the following ...
It's a little involved but should work - at some point I'd like to update the extensibility to make this kind of thing a little easier. Cheers |
The MapType method looks like the way to go for me as well, I was doing something with a custom parameter binding for file uploads and ran into the stack overflow as well. Cause was similar to this (FileInfo was on another type):
|
Hey So, I think I have the infinite loop problem fixed. I've implemented progress tracking within the recursive calls to detect self-references and act accordingly It's currently in a branch called "fix_infinite_loop_issue" I'd be very grateful if you could pull this down and ensure your original issue doesn't repro Thanks |
Fixed and released as of version 3.1.1 |
I am seeing infinite stack related to JToken again in 4.0 |
Hey @VaclavK Can you elaborate a little more on this so I can get a repro? If you can provide me with your action signature (or a sample one that causes the issue) it would be very helpful. Also, it's unlikely that I'll get a fix pushed in the next week as I'm currently doing a lot of Ruby work and am without a .Net development environment. I should be up and running again this weekend though and will get to this as soon possible. |
This is my method signature (which I think is pretty valuable as to enforce JSON constraint while not enforcing full strong type validation - e.g. http://www.hanselman.com/blog/TinyHappyFeatures2ASPNETWebAPIInVisualStudio2012.aspx) public HttpResponseMessage Post([FromBody] JToken data) JToken is public abstract class JToken : IJEnumerable, IEnumerable, ... and this is where the infinite loop resides I "fixed" it for now using the same strategy as the thread above uses c.MapType(() => { .... |
I've just pushed a pre-release version (4.1.0-rc1) including a fix for this issue. If you get a spare moment, I'd really appreciate you taking the time to test it out and confirm your issue has been resolved.
Let me know how it goes Thanks Richie |
Yes it is working - showing as string, which is technically correct of course but slightly obscures that the controller is actually using JObject in its signature (it would highlight the input needs to be JSON as opposed to any string) Vaclav I've just pushed a pre-release version (4.1.0-rc1) including a fix for this issue. If you get a spare moment, I'd really appreciate you taking the time to test it out and confirm your issue has been resolved. Install-Package Swashbuckle -Pre Let me know how it goes Thanks Richie — |
I have the following signature in an API Controller:
It looks like the SwaggerGenerator goes into an infinite loop when it tries to reflect that method:
That calls CreateContainerSpec, which calls CreateModelSpec, which calls CreateContainerSpec ad infinitum. The System.Type it's getting is a JToken:
The text was updated successfully, but these errors were encountered: