fix: fix type of payload in MessageExample#561
Conversation
Pakisan
requested review from
GreenRover,
asyncapi-bot-eve,
char0n,
dalelane,
derberg,
fmvilas,
jonaslagoni and
smoya
as code owners
Rollback headers to Map[string, any]
Pakisan
changed the title
Update headers description. Clarify that headers must be a map of key-value pairs
| "description": "Example of the application 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 <fmvilas@gmail.com>
|
|
yo, how is this one going? we need it for asyncapi/spec#1082 to be merged |
dalelane
left a comment
dalelane
left a comment
There was a problem hiding this comment.
Not sure I've fully considered the impact on all protocols, but from a Kafka perspective this is a reasonable restriction to add
|
🎉 This PR is included in version 6.8.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
5 participants
Define
payloadasanytypeFixes #560