As one can see field with reference ⌿definitions⌿User⌿counts refers typedef with reference ⌿paths⌿/users/{user-id}⌿get⌿responses⌿200⌿data⌿counts which is incorrect.
This happens only with objects inside other objects because function fromTypes replaces name for all fields on the first level of an object.
The actual issue is that the next step - flattener might extract type with wrong type reference. This will cause modelConverter to fail while resolving type using not existent reference.
Reasoning:
When parser creates the model it creates invalid references e.g.:
https://github.com/zalando/api-first-hand/blob/master/swagger-parser/src/test/resources/expected_results/types/instagram.api.yaml.types#L814
As one can see field with reference
⌿definitions⌿User⌿counts
refers typedef with reference⌿paths⌿/users/{user-id}⌿get⌿responses⌿200⌿data⌿counts
which is incorrect.This happens only with objects inside other objects because function
fromTypes
replaces name for all fields on the first level of an object.The actual issue is that the next step - flattener might extract type with wrong type reference. This will cause modelConverter to fail while resolving type using not existent reference.
Currently type flattener tests don't fail because during flattening of instagram api example flattener imports right
⌿definitions⌿User
mapping after the incorrect one during the same iteration on https://github.com/zalando/api-first-hand/blob/master/api-first-core/src/main/scala/de/zalando/apifirst/TypeFlattener.scala#L127But it might be a case if
typeDefs
map will have different ordering.This pr fixes initial issue in the parser.