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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Pakisan
Copy link
Member

@Pakisan Pakisan commented Dec 30, 2024

Define payload as any type

Fixes #560

Rollback headers to Map[string, any]
@Pakisan
Copy link
Member Author

Pakisan commented Jan 9, 2025

@Pakisan Pakisan changed the title fix: fix type of payload and headers in MessageExample fix: fix type of payload in MessageExample Jan 9, 2025
@@ -23,7 +23,7 @@
"description": "A brief summary of the message example."
},
"headers": {
"type": ["number", "string", "boolean", "object", "array", "null"],
"type": "object",
"description": "Example of the application headers. It can be of any type."
Copy link
Member

Choose a reason for hiding this comment

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

Please change the description too 🙏

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

Update headers description. Clarify that headers must be a map of key-value pairs
@Pakisan Pakisan requested a review from fmvilas January 10, 2025 17:12
definitions/3.0.0/messageExampleObject.json Outdated 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.

Co-authored-by: Fran Méndez <fmvilas@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] fix type of payload in MessageExample
2 participants