Error: Too many levels of nesting to fake this schema

[umnex]

Is there an existing issue for this?

• [X] I have searched the tracker for existing similar issues and I know that duplicates will be closed

Describe the Issue

When I use nesting in my OpenAPI definition and generate collection. The generated examples where nesting has been used show the following error:

Sample generated Example: { "meta": { "page_size": 50, "continuation_token": "A Very Long JSON String" }, "data": [ { "service": { "id": "bc73d72d-3cca-433b-8229-ab8fd0f7c2f1", "name": "Software Development" }, "posted_by": { "id": "05072d22-ab35-47ce-8d58-4ffe0d6fcda7", "name": "John Wick", "city": "Toronto", "country": "Canada", "phone": "+1 ***-***-3006", "phone_verified": true, "email": "us***@****.com", "email_verified": false, "posted_on": "2017-07-21T17:32:28Z" }, "id": "05072d22-ab35-47ce-8d58-4ffe0d6fcda7", "lead_status": "pending", "credits": 22, "experts_responded": 3, "service_questions_and_answers": [ { "question_id": { "value": "" }, "question": { "value": "" }, "answer": { "value": "" } }, { "question_id": { "value": "" }, "question": { "value": "" }, "answer": { "value": "" } } ] }, { "service": { "id": "bc73d72d-3cca-433b-8229-ab8fd0f7c2f1", "name": "Software Development" }, "posted_by": { "id": "05072d22-ab35-47ce-8d58-4ffe0d6fcda7", "name": "John Wick", "city": "Toronto", "country": "Canada", "phone": "+1 ***-***-3006", "phone_verified": true, "email": "us***@****.com", "email_verified": false, "posted_on": "2017-07-21T17:32:28Z" }, "id": "05072d22-ab35-47ce-8d58-4ffe0d6fcda7", "lead_status": "pending", "credits": 22, "experts_responded": 3, "service_questions_and_answers": [ { "question_id": { "value": "" }, "question": { "value": "" }, "answer": { "value": "" } }, { "question_id": { "value": "" }, "question": { "value": "" }, "answer": { "value": "" } } ] } ] } ### Steps To Reproduce 1. Import attached API Spec 2. Generate Collection 3. View generated successful response example under Leads --> [admin,client,expert] Returns lead list ### Screenshots or Videos  [Spec.txt](https://github.com/postmanlabs/postman-app-support/files/8729608/Spec.txt) ### Operating System Windows ### Postman Version 9.18.2 ### Postman Platform Postman App ### Additional Context? _No response_

[timbochamp]

Hi @umnex , thanks for reporting. I'm not able to reproduce using your example when importing when using path or tags folder organization. It looks at first glance like the 10 stack limit nesting level hasn't been reached either.

Is there a different example you're using that has more nesting happening? To get around these limits, I'd recommend checking out the openapi-to-postman project and this thread in particular where these limits are discussed for how to bypass them: https://github.com/postmanlabs/openapi-to-postman/issues/306

[umnex]

Sorry I attached the spec where i solved the issue by removing the nesting. Here is the spec sample that generates issues. spec_with_issues.txt

[umnex]

Hi, Is there any update to this issue?

[timbochamp]

Sorry for the delay, @umnex. I've added a feature tag here for our Product team to review this as a feature request where the implementation will likely take time. It is a fixed limit of 10 levels of nesting I believe.

As mentioned in my last post, to get around these limits, I'd recommend checking out the openapi-to-postman project and this thread in particular where these limits are discussed for how to bypass them: postmanlabs/openapi-to-postman#306 if that's a feasible workaround in the meantime?

[umnex]

Thanks for the update. I don't think I passed the 10 levels limit in my spec. Can you confirm it please?

[timbochamp]

Let me check with our team just to be sure!

[timbochamp]

@umnex sorry to be mistaken on my part! I spoke with @VShingala and the "Too many levels of nesting to fake this schema" problems are due to how big the spec is where there are only six layers of nesting.

As a workaround, you can turn off Optimize Conversion setting, which should prevent the deeper layers of nesting from being populated with "Too many levels of nesting to fake this schema". I verified this with your file as well.

[timbochamp]

Going to close this out but feel free to reopen it if this issue is persisting! I'll log a ticket internally to try to better this error messaging where it's not intuitive to know to disable this Optimize conversion setting I realize.

[umnex]

Thank you!

[pierre-wehbe]

Hi Team,

Turning off Optimize Conversion setting via UI does work. Is there a way to do that via the Postman API?

I am using the Automation-API Workflow and still getting the error. Documentation is not clear/ doesn't show settings available in the UI

https://www.postman.com/postman/workspace/api-first-workflow-patterns/collection/15950784-a44c86f0-a7ab-4d17-afe0-d0d5ab393b91?ctx=documentation

@timbochamp

[sagaofsilence]

@umnex sorry to be mistaken on my part! I spoke with @VShingala and the "Too many levels of nesting to fake this schema" problems are due to how big the spec is where there are only six layers of nesting.

As a workaround, you can turn off Optimize Conversion setting, which should prevent the deeper layers of nesting from being populated with "Too many levels of nesting to fake this schema". I verified this with your file as well.

Turning off "Optimize conversion" worked for me... thanks a lot.

[pierre-wehbe]

@umnex @timbochamp Just making sure this doesn't get lost in translation, this works if we were to use the POSTMAN UI to import, but doesn't work via API (no field to turn off optimize conversion. Any suggestions?

[timbochamp]

@pierre-wehbe have you tried openapi-to-postman as a workaround? https://github.com/postmanlabs/openapi-to-postman/issues/306#issuecomment-901946755

You should be able to set optimizeConversion=false that way I want to say!

[TeymurovFuad]

Hi Team,

Turning off Optimize Conversion setting via UI does work. Is there a way to do that via the Postman API?

I am using the Automation-API Workflow and still getting the error. Documentation is not clear/ doesn't show settings available in the UI

https://www.postman.com/postman/workspace/api-first-workflow-patterns/collection/15950784-a44c86f0-a7ab-4d17-afe0-d0d5ab393b91?ctx=documentation

@timbochamp

Same here

[voodooism]

Turning off Optimize Conversion doesn't work for me. I use collection from here: https://developer.mastercard.com/mdes-digital-enablement/documentation/api-reference/

[Gunacan]

I am also using the POSTMAN UI to import, and turning off the "Optimize Conversion" setting doesn't work. I am still getting the "" error.

I am also not able to tell if I've reached the 10 stack limit nesting as I am not sure how exactly that's measured. Are there any updates on when this feature will be implemented?

[iksflow]

@Gunacan I got a same problem and I found a solution! It worked really well for me.

openapi2postmanv2 -s root.yaml -o collection.json -p -O folderStrategy=Tags,includeAuthInfoInExample=false,optimizeConversion=false,stackLimit=50

[Gunacan]

@iksflow, thanks for your response, but as I said in my message, I am doing the import on Postman UI (Postman app), and not the API. The UI doesn't have the feature to set the stack limit yet; currently, you can only achieve this using the API which is what you're doing it looks like.

[iksflow]

@Gunacan Yeah, that's right. It's not cool. You already know, So I imported the collection.json(generated by CLI command) to Postman App. 🤣

[karl-cardenas-coding]

This ticket should not be marked closed as the root cause has not really been addressed.

[timbochamp]

Reopening to track with ticket internally to try to better this error messaging or arrive at a solution not requiring openapi-to-postman as a workaround

[lanshunfang]

No, openapi-to-postman doesn't work for me. It's even worse because it generates only 2 levels when it comes to this situation.

[maldaba-nigel]

I, too, am encountering the "" error, but the suggested work-around of using openapi2postmanv2 -s root.yaml -o collection.json -p -O folderStrategy=Tags,includeAuthInfoInExample=false,optimizeConversion=false,stackLimit=50 Doesn't work for me. I still get the error in the imported collection, and from the output when running openapi2postmanv2, it doesn't seem to be using more than a stack of 10,despite being told to use up to 50:

openapi2postmanv2 -s postman.yml -o collection.json -p -O folderStrategy=Tags,requestParametersResolution=Schema,optimizeConversion=false,stackLimit=50 Warning: Invalid option supplied folderStrategy Input file: C:\Users\Nigel\Documents\postman.yml Writing to file: true C:\Users\Nigel\Documents\collection.json { result: true, output: [ { type: 'collection', data: [Object] } ], analytics: { actualStack: 10, numberOfRequests: 4, size: 0.008146286010742188, numberOfRefs: 15, numberOfExamples: 37, assignedStack: 10, complexityScore: 0 } } Conversion successful, collection written to file This is using openapi2postmanv2 v4.9.0 Any suggestions?

[pmrussell892]

Following, I also have the issue.

[mbablok]

Using Version 10.11.1 of Postman UI and the setting does not work for me.

[anandsunderraman]

Using Version 10.11.2 of Postman UI and the setting does not work for me.

[maldaba-nigel]

I have come back to this issue after a period of time working on other things and have stumbled-upon a solution.

It seems that if you pass the config options on the command-line, e.g: openapi2postmanv2 -s postman.yml -o collection.json -p -O folderStrategy=Tags,requestParametersResolution=Example,optimizeConversion=false,stackLimit=50 you get the "" error, but if you pass the same parameters in a JSON config file, e.g. openapi2postmanv2 -s postman.yml -o collection.json -c config.json where config.json contains:

{
  "optimizeConversion": true,
  "folderStrategy": "Tags",
  "requestParametersResolution": "Example",
  "optimizeConversion": false,
  "stackLimit": 50
}

it works as expected, with no error generated. In my case, it now claims to be using a stack of depth 11.

[VShingala]

@maldaba-nigel I tried this out myself with stripe API which has maximum of 27 nested levels and using same args provided as you, it's generating collection without any "<Error: Too many levels of nesting to fake this schema>" error in collection.

Could it be the case that the OpenAPI definition you're working with has more than 50 levels of nesting?

[VShingala]

Hey Everyone, with the recent Postman app release v10.12. We've made changes to how we generated the collection from OpenAPI definitions. To solve this issue, we've made many performance improvements and have removed the default option called Optimize conversion which was restricting the amount of nested data that was resolved.

We've also increased this limit till which we used to resolve nested data by 3 times (Now, we resolve till 30 levels of nested schema objects instead of the previous 10 levels).

Please, let us know your feedback on this if you're still facing this issue. We'll keep this issue open for some time to collect more feedback.

[shae128]

I still have this issue

[pmrussell892]

I have updated to V10.13 and still have the issue.

[VShingala]

@shae128 @pmrussell892 If possible you be able to share the definition / sample definition where this issue is still reproducible?

It's still possible to have this error if there is too much nesting in the data. i.e. more than 30 levels. But many cases are now generat8ing collection without this. For example, Here's Stripe API which used to have this limitation but with this change, generated collection from this now does not contain such error.

[pmrussell892]

Is their any plans to allow users to change the stack limit using Postman settings? I unfortunately cannot share the definition and API.json files being used per company policy. It is a private api

[VShingala]

@pmrussell892 We're looking more into this. Meanwhile, you can make use of our open-source collection generator from OpenAPI definition.

Here is more on how this tool can be installed and used. This conversion will take place on your machine so it'll be private. Do provide your feedback if increasing this limit is generating collection as expected or not.

[jstjoe]

Bumping this. It's been over a year since this last message:

We're looking more into this. Meanwhile, you can make use of our open-source collection generator from OpenAPI definition.

How's the looking going?

[VShingala]

@jstjoe With the current limit that we have in place (stack=30) most of the use-cases should not be having this issue. But if you have this issue occurring where even for a property that is not very nested and you receive this error, let us know and we can look into it.

As for exposing this option in App, It seems allowing this option could cause many potential issues due to sheer amount of collection size that few definitions that are imported can generate. We've seen collections getting generated that are more then 500 MB to even 1 GB in such cases. Due to this, we've made decision to allow such generation only from usage of module directly.