Skip to content

fix: fix type of payload in MessageExample #561

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.

Sign up for GitHub

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

Merged
Pakisan merged 4 commits into from
Jan 27, 2025
Merged

fix: fix type of payload in MessageExample #561

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8aac004
fix: fix type of payload and headers in MessageExample
Pakisan Dec 30, 2024
21c25a4
fix: wrong type of payload and headers in MessageExample
Pakisan Jan 9, 2025
dffbf5d
fix: headers description in MessageExample
Pakisan Jan 10, 2025
20d0e0c
Update definitions/3.0.0/messageExampleObject.json
Pakisan Jan 10, 2025
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
3 changes: 2 additions & 1 deletion definitions/3.0.0/messageExampleObject.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,9 +24,10 @@
},
"headers": {
"type": "object",
"description": "Example of the application headers. It can be of any type."
"description": "Example of the application headers. It MUST be a map of key-value pairs."
},
"payload": {
"type": ["number", "string", "boolean", "object", "array", "null"],
Copy link
Member

@fmvilas fmvilas Jan 10, 2025

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

@Pakisan Pakisan Jan 10, 2025

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

@fmvilas fmvilas Jan 10, 2025

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

@Pakisan Pakisan Jan 10, 2025

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

@fmvilas fmvilas Jan 10, 2025

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

@Pakisan Pakisan Jan 10, 2025

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

@fmvilas fmvilas Jan 10, 2025

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