CLI-3551: asyncapi export generates an invalid file with $ref paths that are incorrect

[TimButterfield]

I've been evaluating the async api export from schema registry to see I can line up Confluent, AsyncApi and EventCatalogue to help my client document their estate. However, the file that confluent asyncapi export command generates isn't valid.

Steps that I used to produce an error

1. Push event that has an object hierarchy (see below) to a new topic with scheme generation on, such a new schema is registered.
2. Perform all of the pre steps from the Confluent docs about choosing the right environment / cluster / schema reg in the Cli.
3. Run the Cli async api export command to generate a file
4. Install the AsyncApi-Preview tool for VSCode
5. After the file has generated, open the file in VS code use the VS command palette to run AsyncApi Preview
6. Note the errors generated

"line {line number}: '#/definitions/{typenamehere}' does not exist"

The path should be '#/components/messages/{messagenamehere}/payload/definitions/{typenamehere}'

NOTE: The same error occurs if you take the file generated and view on the AsyncApi page in the Studio tool.

Example C# object

`public class Foo { public Bar Bar {get; set;} }

public class Bar { .... }`

[sajjadlateef]

Which version of the AsyncAPI spec are you using? The export is supposed to work with AsyncAPI v2.4 ... we do currently support AsyncAPI v3.0 but it is on our roadmap

There are tools in the AsyncAPI website for converting v2.4 to v3.0 . Please see if those tools can help you.

[TimButterfield]

Hi @sajjadlateef. Thank you for the suggestion. I used the tool on the AsyncApi site to convert the schema registry exported async api file from version 2.4 to 3.0, but the problem persisted. The document that was output still contained many #/definitions/{typenamehere} which the other tools (VSCode / AsyncApi Stuido) remain unhappy with. There was no conversion from #/definitions/{typenamehere} to anything else.

It's unclear to me as to whether a $ref: #/definitions/{typenamehere} was valid in 2.4, but is now incompatible with the other current async api tooling, or if the document exported from the SchemaRegistry is malformed. I welcome your input on this.

Many thanks

[sajjadlateef]

Thank you for the update, @TimButterfield .

This is likely a bug in the AsyncAPI export. We will file an internal ticket and work on this.