-
Notifications
You must be signed in to change notification settings - Fork 211
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 on recursive oneOf component #451
Comments
Any idea / suggestion on how to work around this issue? |
I might have found the root cause, checkAmbiguousMemberTypes needs to be moved after assigning I tried with my schema and it worked with that change. I could submit a pull request but I'm not too familiar with github and I don't know how to do that (I tried creating a separate branch and pushing it but I don't have permission). I also couldn't write a proper unit tests for that, if the schema is too simple then GraphQL will complain:
I could spend more time trying to write a proper unit-test, but I'd like to have confirmation from someone first, since that issue doesn't seem to have much traction. |
I got some help and figured out how to submit a pull request (#457). |
Any update? |
Describe the bug
Given a schema that has a recursive
oneOf
element, openapi-to-graphql fails to generate the graphql schema with aMaximum call stack size exceeded
error. I suspect there is an infinite loop while trying to convert the recursive element.I'm using Smithy (union type) to generate the openapi file (see section below for openapi file). I came across that issue when trying to model arithmetic expressions. Here is an example with recursive
oneOf
:To Reproduce
Steps to reproduce the behavior:
openapi-to-graphql RecursionExample.swagger.api.json.txt
(using"openapi-to-graphql-cli": "2.6.3"
)Maximum call stack size exceeded
Expected behavior
I'd expect openapi-to-graphql to not fail to generate the schema, and to, by order of preference:
Example of ideal union type that should be generated (if possible):
Example of alternative that would still be acceptable:
This is not great as we lose the concept of union type, but it is better than having the whole schema generation failing.
Finally, if none of those are possible, JSON would be a last resort.
The text was updated successfully, but these errors were encountered: