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: fix type of payload in MessageExample #561

Merged
merged 4 commits into from
Jan 27, 2025
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions definitions/3.0.0/messageExampleObject.json
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,7 @@
"description": "Example of the application headers. It can be of any type."
fmvilas marked this conversation as resolved.
Show resolved Hide resolved
},
"payload": {
"type": ["number", "string", "boolean", "object", "array", "null"],
Copy link
Member

Choose a reason for hiding this comment

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

Why maintaining a list of types here? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

In previous versions here was any type. I found in SO that's better way to simulate any type and don't broke validation is to enumerate each JSON Schema type

Copy link
Member

Choose a reason for hiding this comment

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

Why is it going to break validation? When type is not specified, it can be any type, right? If some tools don't get it right, shouldn't it be fixed in the tools instead?

Copy link
Member Author

Choose a reason for hiding this comment

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

I have checked and yes, it's working. But according to type definition it must be string or array of strings

I found only one comment from 2015, where not presented type means any

@jviotti what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

It's either a string or an array of strings but it's not required, so we can decide not to put it there. Effectively, I think it means "any" but good idea pinging the JSON Schema folks as, in the end, they know best.

Copy link
Member Author

Choose a reason for hiding this comment

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

Anyway, I'm ready to remove type and patch our schema for JetBrains IDE and other validators, as I have already done, previously

My main concern is to try to bring changes back, here, to make our schema compatible with various IDEs and environments where AsyncAPI specification will be validated via our JSON Schemas

And be sure that this changes are synced with JSON Schema specification requirements

Copy link
Member

Choose a reason for hiding this comment

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

Understandable mate. It's a fine line between trying to be pragmatic and keeping the spec strict. I'm not against maintaining this list of types but code you don't write is code you don't have to maintain. Arguably, explicit is better than implicit. Let's see what others have to say 🤷‍♂️ I'm not going to block this PR because of this line.

"description": "Example of the message payload. It can be of any type."
}
},
Expand Down
Loading