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

feat: add core message payload validation #334

Conversation

jonaslagoni
Copy link
Member

@jonaslagoni jonaslagoni commented Feb 9, 2023

Description
This PR enables the following:

  1. It conditionally validates the message payload against two core schemas, our AsyncAPI Schema object (default) and the raw JSON Schema draft 7.
  2. It defaults to validating the AsyncAPI schema object, if no specific schema format has been selected
  3. Indirectly, this enables auto-completion for editors when writing the message payload

Fixes #166
Blocked by #333

@jonaslagoni jonaslagoni changed the title feat: add conditional message payload validation feat: add basic message payload validation Feb 22, 2023
@jonaslagoni jonaslagoni marked this pull request as ready for review February 22, 2023 19:03
@jonaslagoni jonaslagoni changed the title feat: add basic message payload validation feat: add core message payload validation Feb 22, 2023
@jonaslagoni jonaslagoni marked this pull request as draft February 22, 2023 21:21
@sonarcloud
Copy link

sonarcloud bot commented Feb 22, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

Comment on lines +182 to +202
"application/vnd.aai.asyncapi;version=2.0.0",
"application/vnd.aai.asyncapi+json;version=2.0.0",
"application/vnd.aai.asyncapi+yaml;version=2.0.0",
"application/vnd.aai.asyncapi;version=2.1.0",
"application/vnd.aai.asyncapi+json;version=2.1.0",
"application/vnd.aai.asyncapi+yaml;version=2.1.0",
"application/vnd.aai.asyncapi;version=2.2.0",
"application/vnd.aai.asyncapi+json;version=2.2.0",
"application/vnd.aai.asyncapi+yaml;version=2.2.0",
"application/vnd.aai.asyncapi;version=2.3.0",
"application/vnd.aai.asyncapi+json;version=2.3.0",
"application/vnd.aai.asyncapi+yaml;version=2.3.0",
"application/vnd.aai.asyncapi;version=2.4.0",
"application/vnd.aai.asyncapi+json;version=2.4.0",
"application/vnd.aai.asyncapi+yaml;version=2.4.0",
"application/vnd.aai.asyncapi;version=2.5.0",
"application/vnd.aai.asyncapi+json;version=2.5.0",
"application/vnd.aai.asyncapi+yaml;version=2.5.0",
"application/vnd.aai.asyncapi;version=2.6.0",
"application/vnd.aai.asyncapi+json;version=2.6.0",
"application/vnd.aai.asyncapi+yaml;version=2.6.0",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because there are no changes to the schema across all v2 versions and v3, I guess it makes sense to validate it against these, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it does make sense. Better to be explicit ;]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about having to maintain this list, add new elements per version, etc.

Can we use a pattern instead of enum here?

{
  "type": "string",
  "pattern": "^application\\/vnd\\.aai\\.asyncapi(\\+json|\\+yaml)?;version=\\d+\\.\\d+\\.\\d+$"
}

Maybe some change is needed. You can test it in https://www.jsonschemavalidator.net/s/VTaBCoGr

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure we dont want to enable v1 or future v4 schemas here right? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also would we not want to explicitly state which schema formats are allowed as values? Using something like v2.69.0 would not give a validation error with regex 🤔

Unless you explicitly add a range, but then you are back to having to change this each version anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

Also thinking about new features being added between versions (no breaking changes). For example, let's say 3.1.0 introduces a new field in the schema so you will have to do a split, serving one schema for >=2.x <=3.0, and another for 3.1.

Porting this to the pattern will be a bit messy. I don't like to maintain all this list but indeed i can't find a better alternative ATM but automating somehow this (we can think about in near future).

@jonaslagoni jonaslagoni marked this pull request as ready for review February 22, 2023 22:11
Copy link
Member

@smoya smoya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@smoya smoya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jonaslagoni
Copy link
Member Author

/rtm

@asyncapi-bot
Copy link
Contributor

🎉 This PR is included in version 5.0.0-next-major-spec.14 🎉

The release is available on:

Your semantic-release bot 📦🚀

@asyncapi-bot
Copy link
Contributor

🎉 This PR is included in version 6.0.0-next-major-spec.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants