Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared avro model results in incorrect AsyncAPI document #1075

Closed
hguidetti opened this issue Nov 24, 2023 · 4 comments
Closed

Shared avro model results in incorrect AsyncAPI document #1075

hguidetti opened this issue Nov 24, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@hguidetti
Copy link

hguidetti commented Nov 24, 2023

Describe the bug

Hello,

I have an AsyncAPI file that uses referenced Avro schemas. One schema is shared between 2 referenced schemas.
In my example, I have a User and a Pet which both have an Address that is referenced in the avsc file using

  "fields" : [
        ...
        {
            "name" : "address",
            "type" : "com.example.Address"
        }
    ]

When I generate the documentation (for example), I receive an error Generator Error: Input is not a correct AsyncAPI document so it cannot be processed.

How to Reproduce

I have created a little example on my GitHub https://github.com/hguidetti/asyncapi-avro-shared-model to reproduce.

Run generate-correct.sh to verify that the generation works correctly. (I used latest version of the Docker image asyncapi/cli but with HTML template @0.28.4 to work around asyncapi/html-template#456)

Run generate-wrong.sh to see that the generator sends Generator Error: Input is not a correct AsyncAPI document so it cannot be processed.

I also tried with VS Code and the AsyncAPI plugin and it doesn't work neither. I receive the error Error: undefined type name: com.example.Address

Expected behavior

The AsyncAPI should be correct. (Or do I do anything wrong ?)

@hguidetti hguidetti added the bug Something isn't working label Nov 24, 2023
Copy link
Contributor

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

@hguidetti hguidetti changed the title Shared avro model result in incorrect AsyncAPI document Shared avro model results in incorrect AsyncAPI document Nov 28, 2023
@hguidetti
Copy link
Author

This issue is probably a duplicate of asyncapi/avro-schema-parser#190

@hguidetti hguidetti closed this as not planned Won't fix, can't repro, duplicate, stale Nov 28, 2023
@hguidetti hguidetti reopened this Nov 28, 2023
@hguidetti
Copy link
Author

I understand that for asyncapi/avro-schema-parser#190 it not at avro-schema-parser level, maybe there is anything to do at generator level ?

Would it be possible to have a kind of Model Store ? So if I have a reference to com.example.Address, it will find the model. The dependency tree has to be determined first and then the model must be treated in the correct order (from the less dependent to the most ones).

@derberg
Copy link
Member

derberg commented Jan 17, 2024

@hguidetti there is not much we can do on generator level. Generator 100% relies on AsyncAPI object provided by https://github.com/asyncapi/parser-js. The parser is the tool where something like what you need could be provided - not sure how though. Maybe concept of custom schema parser should be extended to allow owners of parsers like avro-schema-parser to somehow prebundle schemas or something.

anyway, definitely nothing we can do in generator other than use what parser provides.

please open a separate issue in Parser with full explanation of problem. I will close this issue for now

@derberg derberg closed this as completed Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants