fix: fix type of payload in MessageExample #561
Conversation
Pakisan
requested review from
fmvilas,
derberg,
dalelane,
smoya,
char0n,
GreenRover,
jonaslagoni and
asyncapi-bot-eve
as code owners
Rollback headers to Map[string, any]
Pakisan
changed the title
| @@ -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." | |||
There was a problem hiding this comment.
Please change the description too 🙏
Update headers description. Clarify that headers must be a map of key-value pairs
| }, | ||
| "payload": { | ||
| "type": ["number", "string", "boolean", "object", "array", "null"], |
There was a problem hiding this comment.
Why maintaining a list of types here? 🤔
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 <[email protected]>
|
Define
payloadasanytypeFixes #560