Rendering doesn't appear correct when a "reply:" is included in an operation.

[AMulgrave]

The rendering seems to be getting it wrong when "reply:" is present in an operation definition.

Operation OnBlockRun1 is a SEND yet it is rendered as RECEIVE.
Operation OnBlockRun2 is rendered correctly.

Also, the "REPLY INFORMATION" block is rendering the request channel rather than the reply channel.

Note, I also observed this behavior in Asyncapi Studio.

`asyncapi: 3.0.0
info:
title: demonstrate defect
version: 1.0.0
description: description

channels:
Block:
address: device.v1.request.{id}.block
messages:
BlockSend:
$ref: '#/components/messages/Block'
BlockReply:
address: device.v1.reply.{id}.block
messages:
BlockReturn:
$ref: '#/components/messages/BlockReply'

operations:
onBlockRun1:
action: send
channel:
$ref: '#/channels/Block'
messages:
- $ref: '#/channels/Block/messages/BlockSend'
reply:
address:
location: '$message.header#/ReplyTo'
channel:
$ref: '#/channels/BlockReply'
messages:
- $ref: '#/channels/BlockReply/messages/BlockReturn'
onBlockRun2:
action: send
channel:
$ref: '#/channels/Block'
messages:
- $ref: '#/channels/Block/messages/BlockSend'

components:
schemas:
BlockIdentifier:
description: Uniquely identifies a block, important for run, clear and hold actions.
type: object
properties:
Id:
type: string
format: guid
Name:
type: string
HeaderBody:
type: object
properties:
SpanId:
description: The span identifier for OpenTelemetry. Typically this would be a guid.
type: string
ReplyTo:
description: The url to send the reply message to. This is only valid for request messages.
type: string

messageTraits:
MessageBase:
headers:
$ref: '#/components/schemas/HeaderBody'
correlationId:
description: The span identifier for OpenTelemetry.
location: $message.header#/SpanId

messages:
Block:
traits:
- $ref: '#/components/messageTraits/MessageBase'
payload:
type: object
properties:
Identifier:
$ref: '#/components/schemas/BlockIdentifier'
Action:
type: string
description: valid values:- clear | run | hold
BlockReply:
payload:
type: object
properties:
Identifier:
$ref: '#/components/schemas/BlockIdentifier'
Action:
type: string
description: valid values:- clear | run | hold

parameters:
id:
description: The ID of the device`

[ivangsa]

Hi @AMulgrave

thanks for taking the time for reporting this

This vscode extension uses this component https://github.com/asyncapi/asyncapi-react
It is also the same web component used here https://studio.asyncapi.com/

If it looks like a rendering problem of the react component, you will get better results reporting the issue directly to the react component

[AMulgrave]

Hi @ivangsa
I suspected it was a react component issue, however, the defect should be logged here as it is the end product that the user sees.
Also, react 1.2.13 partially fixes this issue and I believe this product is still running with react 1.2.7.

thank you for you time and a great product.

[JustinKlimBR]

Is there any word on when a fix for this might be possible? The same issue no longer seems to impact https://studio.asyncapi.com/ so it seems this plugin has fallen comparatively out of date.

[ivangsa]

Hi @JustinKlimBR

we just have release a new version with the latest

but this error seems to also be present in AsyncAPI Studio @asyncapi/react-component

So you mind opening this issue in the @asyncapi/react-component

[JustinKlimBR]

@ivangsa I'm not sure that's a bug rather than an interpretation and one intended to provide additional clarity to the reader of the API.

The component seems to have two labels for operations with the "send" action depending on whether any reply messages are configured. They use "SEND" for operations with no reply entries (i.e. you only send and there is no direct response) and "REQUEST" where the operation has one or more reply entries (i.e. you send a request and get a reply).

That makes sense to me (whether I agree with the labels of not is a different matter of course :) ).

But thanks for the swift response and the version upgrade. It's a perfect fix for me!