When generating output a schema property is being ignored/skipped

[gablabelle]

Describe the bug

When generating output a property is being ignored/skipped. I'm pretty new to yaml files, I just hope I'm doing some silly mistake and forgetting something. ;-)

To Reproduce
Steps to reproduce the behavior:

Checkout the generate-bug-type-property branch of the following repo: https://github.com/gablabelle/next-mesh-apollo-monorepo-example/tree/generate-bug-type-property

Run yarn and cd packages/graphql-server

You can now take a look to the test.yaml where v5_approvalRequest_approvalRequestSummaryGet contains the type and type2 fields pointing to the same ref.

Run yarn mesh:generate:typings to generate output ts file.

See the missing type field from V5ApprovalRequestApprovalRequestGet but type2 is present.

N/A
Expected behavior

Both type and type2 fields should be present in the output

Environment:

• OS: Mac Big Sur

• @graphql-mesh/...:
  

• NodeJS: v14.15.4

Additional context

N/A

[gablabelle]

@ardatan Sorry to mention you like this, but do you have any idea what could cause this?

[santino]

The problem here does not come from the fact that two properties are pointing to the same reference.
The problem is simply that the name of the property type is a reserved name.
Things like type and properties are reserved keywords in OpenAPI specifications, since they are used to define the document.

If you change the name of type to type1, things will work as expected.

After identifying the issue, I looked on the internet to see if I could find any reference to it.
Seems like it used to be a problem but it was fixed in swagger-js in 2017, see here for reference.
If this is the case, I believe further debugging would be required in Mesh to check why this is not working.
Might be something outdated in openapi-to-graphql library used internally by the openapi handler.

In the meantime, I hope you can simply chose a different name for the keyword.

[gablabelle]

@santino Thanks for your feedback. Yes Type2 was just an example to showcase the behaviour and the fact that it was working when renamed.

It's weird because we have other working usages of type in response payloads in our swagger files that work fine.

Unfortunately we can't change the APIs, we simply consume them.

[santino]

Ok, so this is for a remote API you consume, not a specification yaml built locally.

Have you looked into the rename transform?
That can help to rename the offending property name.
I suggest you try using it in bare mode.
Take a look at the documentation and have a play.

Of course, renaming the property name is just a workaround.
I believe the actual underlying issue still requires some debugging.

[ardatan]

Seems to be fixed in the latest versions;
7a2d597