#4852 Unit test and fix to allow recursive models to process without StackOverflow

[Yaytay]

Pull Request

Description

Bug fix ton undo a tiny part of v2.2.27...v2.2.28#diff-bed6aab5e29942b1a575bded333604f9dfaeb2ef9475f1433266ece4e49f4fcb that introduced a StackOverflow exception on recursive data models with OpenAPI 3.1.

Fixes: #4852

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor (non-breaking change)
• 🧪 Tests
• 📝 Documentation
• 🧹 Chore (build or tooling)

Checklist

• I have added/updated tests as needed
• I have added/updated documentation where applicable
• The PR title is descriptive
• The code builds and passes tests locally
• I have linked related issues (if any)

[ewaostrowska]

hi @Yaytay ,
Thanks for providing this PR. It does help with the issue reported in the #4852 and pointing this spot is already quite helpful for us. Unfortunately we cannot merge this PR yet.

One issue that I see here is that the test ReaderTest.testArraySchemaImplementation is failing with

expected [openapi: 3.1.0
paths:
      items:
        type: number
]

This indicates that items are not resolved correctly after the change.
We need to investigate further on why this boolean property has been added to AnnotationsUtils.getArraySchema.

That extra true argument in 2.2.28 wasn't random — it was almost certainly introduced to fix some other array-handling edge case in the OpenAPI 3.1 path (for example, making sure annotated @ArraySchema metadata such as minItems, uniqueItems, description, proper items resolution, etc., is actually reflected in the generated schema for arrays of complex/polymorphic types).

We need to verify as well how does it influence the OAS 3.x schema as well.

Thanks again for your contribution! We're happy to see any updates from you on this topic :)