🐞 Bug: Example message schemas in AsyncAPI 3.0 spec missing required fields
- Dominant language
- JavaScript
- Stars
- 5.3k
- Forks
- 382
- Avg merge
- 7m
- Merged PRs (30d)
- 4
Description
### Describe the bug
Some example message schemas in the AsyncAPI 3.0 specification do not include all required fields defined in their corresponding component schemas. This makes the examples invalid and may confuse developers who rely on them for correct implementation.
### To Reproduce
Steps to reproduce the behavior:
1. Open the AsyncAPI 3.0 specification repository.
2. Navigate to the `examples/` directory.
3. Inspect a message example (for example, Kafka or AMQP examples).
4. Compare the example fields with the required fields defined in `components/schemas`.
### Expected behavior
All example message schemas should include every required field defined in their corresponding schema definitions.
### Sample document
N/A – issue observed directly in the AsyncAPI 3.0 spec examples.
### Screenshots
N/A – screenshots can be added if a specific example is requested.
### Additional context
This issue affects developers who use the AsyncAPI spec examples as references and may lead to incorrect or invalid implementations. I am happy to contribute a fix by updating the examples if needed.
In the AsyncAPI 3.0.0 specification, some schema examples are not rendered or resolved correctly in the documentation. While the first example is displayed as expected, the other examples do not show their schema structure and appear unresolved or missing in the rendered output. This creates confusion for users trying to understand how multiple schema examples should be defined and used.
Contributor guide
Research direction
Start in the AsyncAPI 3.0 specification repository by comparing the examples/ message examples, including the Kafka or AMQP examples, with required fields in components/schemas. Check the rendered AsyncAPI 3.0.0 documentation for unresolved or missing schema structures; done means affected examples include all required fields and render correctly.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100