You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both asyncapi3-required-operation-channel-unambiguity and asyncapi3-required-channel-servers-unambiguity rules (found here) apply at this moment to the unresolved document, meaning they run when the JSON References ($ref) are not yet resolved.
That was made in this way because it simplifies a lot the logic; we just need to match a pattern to the JSON pointer and voilà!.
However, that simplicity has a cost.
This validation works perfectly when any of the references found in channel.servers or operation.channel point to the same file.
However, if any point to an external file, the validation might not work as expected. See the next section where you will find an example that illustrate this.
# b.yamlasyncapi: 3.0.0info:
title: FileBversion: 1.0.0channels:
test:
servers:
- $ref: '#/components/servers/serverA'# Invalid document. Servers of a channel defined in the root channels object should point to root servers object as well.components:
servers:
serverA:
host: localhostprotocol: http
b.yaml is an invalid document, as explained in the comment of the yaml file. And the parser shows that error when that document is validated.
However, a.yaml, which is referencing an invalid channel from b.yaml file, won't fail validation.
The reason is that the validation is made by matching that the JSON pointer references to the root object. I.e. for operation.channel, the pointer should contain the #/channels/ literal.
Expected behavior
The a.yaml located in the previous example should be considered as invalid by the parser.
I think the only way to achieve this is to make the rules pass when the document is unresolved.
This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Describe the bug
Both
asyncapi3-required-operation-channel-unambiguity
andasyncapi3-required-channel-servers-unambiguity
rules (found here) apply at this moment to the unresolved document, meaning they run when the JSON References ($ref) are not yet resolved.That was made in this way because it simplifies a lot the logic; we just need to match a pattern to the JSON pointer and voilà!.
However, that simplicity has a cost.
This validation works perfectly when any of the references found in
channel.servers
oroperation.channel
point to the same file.However, if any point to an external file, the validation might not work as expected. See the next section where you will find an example that illustrate this.
How to Reproduce
b.yaml
is an invalid document, as explained in the comment of the yaml file. And the parser shows that error when that document is validated.However,
a.yaml
, which is referencing an invalid channel fromb.yaml
file, won't fail validation.The reason is that the validation is made by matching that the JSON pointer references to the root object. I.e. for
operation.channel
, the pointer should contain the#/channels/
literal.Expected behavior
The
a.yaml
located in the previous example should be considered as invalid by the parser.I think the only way to achieve this is to make the rules pass when the document is unresolved.
cc @fmvilas @jonaslagoni @derberg
The text was updated successfully, but these errors were encountered: