feat: report parse failure reasons #1058
Conversation
michael-ball-ctct
requested review from
derberg,
magicmatatjahu,
jonaslagoni and
asyncapi-bot-eve
as code owners
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide 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.
For [](asyncapi#1051) I opted for the more basic logging style - I don't know enough about the diagnostics objects to be sure that they'll always contain the same fields, so erred on the side of caution rather than trying to access fields within fields that aren't guaranteed to exist (as well as including all available information, regardless of what is provided).
michael-ball-ctct
force-pushed
the
report_parse_failure_reasons
branch
from
506dfe8
to
7c98c25
Compare
michael-ball-ctct
changed the title
|
Kudos, SonarCloud Quality Gate passed!
|
|
|
/rtm |
|
🎉 This PR is included in version 1.16.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
@allcontributors please add @michael-ball-ctct for code |
|
Could not find the user |
Description
Adds simple logging for parsing failures, to improve debugging speed and experience of incorrectly formatted asyncapi.yml files for users.
I opted for the more basic logging style of the two I mentioned in the issue - I don't know enough about the diagnostics objects to be sure that they'll always contain the same fields, so erred on the side of caution rather than trying to access fields within fields that aren't guaranteed to exist or adding overcomplicated presence-checking logic (as well as including all available information, regardless of what is provided).
Related issue(s)
Resolves #1051