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

fix: channel parameter not always returning schema #868

Merged

Conversation

jonaslagoni
Copy link
Member

Description
One thing that I found weird while working on asyncapi/markdown-template#360 was that parameter schemas could be undefined with v3 🤔

Cause it should always at least have the schema {type: "string"} and then the rest is optional.

const doc = serializeInput<v3.ParameterObject>({});
const d = new ChannelParameter(doc);
expect(d.hasSchema()).toEqual(false);
expect(d.hasSchema()).toEqual(true);
Copy link
Member

Choose a reason for hiding this comment

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

I agree with the other change but this one is highly debatable. "hasSchema" is meant to tell you if the document has the schema specified, therefore it should be false. However, even though it's false, you should get a default schema in the "schema()" call. These are two different things IMHO.

Copy link
Member Author

Choose a reason for hiding this comment

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

But for v3, you will always have a schema (underneath) as the default behavior is that the parameters are of type: string 🤔 Regardless of what else you define in your parameter.

For v2 it makes sense.

Copy link
Member

Choose a reason for hiding this comment

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

As @fmvilas mentioned, hasSchema is there for answering: Did the user set the schema?

Copy link
Member Author

Choose a reason for hiding this comment

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

But for v3 the schema is always set, even when an empty parameter is defined.

Copy link
Member

Choose a reason for hiding this comment

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

What I mean is if the user has set the schema key. hasSchema answers that question. If the schema key is there, then hasSchema is true, otherwise it's false. Now, the schema() call will always give you a schema because it has a default. Does that make sense?

Copy link
Member

Choose a reason for hiding this comment

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

Alright, discussed offline and this is fine. On v3, there's no schema keyword anymore so it should always be true.

Copy link
Member

Choose a reason for hiding this comment

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

But for v3, you will always have a schema (underneath) as the default behavior is that the parameters are of type: string 🤔 Regardless of what else you define in your parameter.

For v2 it makes sense.

Oh yeah its true😅

@jonaslagoni
Copy link
Member Author

/rtm

@sonarqubecloud
Copy link

sonarqubecloud bot commented Oct 9, 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

@asyncapi-bot asyncapi-bot merged commit 02b06ab into asyncapi:next-major-spec Oct 9, 2023
11 checks passed
@jonaslagoni jonaslagoni deleted the fix_channel_parameters branch October 9, 2023 09:27
@asyncapi-bot
Copy link
Contributor

🎉 This PR is included in version 3.0.0-next-major-spec.5 🎉

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