Operation with both send and receive action

[rzorzorzo]

There are operations which may be both in- and outbound.

example: websocket. operationid: "lock". client sends a message to lock a resource. the server forwards this message to all clients.
the same operation "lock" is therfore sent and received.

How is this specified with asyncapi ?

action can only take the value send or receive. it does not allow a list, nor is send-receive available.
on the other hand in the operations list the operationid is unique, so there is no way to define 2 operations with the same operationid but different action values.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

Hey there, there are not too many details in your question so lemme do some followups.

the same operation "lock" is therfore sent and received.

AsyncAPI document of your client should have a send operation (it sends lock) and reply object (as in reply it gets a message, in this case lock as well). This is the simplest answer I can give. You would have to provide example document, with channel structure, so I can tell you more.

it does not allow a list, nor is send-receive available.

I don't know what you mean really, sorry.

so there is no way to define 2 operations with the same operationid

Can you elaborate more on why would you like to have 2 operations with the same operationId? maybe you have come code you can share already?

Also linking this document that shows different examples on how to use reply object: https://www.asyncapi.com/docs/concepts/asyncapi-document/reply-info

[rzorzorzo]

thanks for the fast reply

AsyncAPI document of your client should have a send operation (it sends lock) and reply object (as in reply it gets a message, in this case lock as well). This is the simplest answer I can give. You would have to provide example document, with channel structure, so I can tell you more.

a reply is the following flow:

client1 -> channel -> client1

what I mean is the following use case: (-> stands for transmitting the lock operation)

client1 -> channel -> client2
at some later time:
client2 -> channel -> client1

a possible specification of this use case would be:

"operations": {
"lock": {
"action": "send",
"channel": {
"$ref": "#/channels/root"
}
},
"lock": {
"action": "receive",
"channel": {
"$ref": "#/channels/root"
}
},
}

which is not possible.
or:

"operations": {
"lock": {
"action": "send-receive",
"channel": {
"$ref": "#/channels/root"
}
},
}

or:

"operations": {
"lock": {
"action":["send", "receive"],
"channel": {
"$ref": "#/channels/root"
}
},
}

hope this helps clarify the requirement.

[shwetd19]

Thanks for the detailed clarification about the websocket lock operation flow. I understand better now - you're describing a pub/sub pattern where any client can both publish and subscribe to the same operation type.

For this use case, I suggest defining separate operations in your AsyncAPI spec to clearly show the bidirectional nature:

channels:
  lock:
    publish:
      operationId: publishLock
      message:
        $ref: '#/components/messages/lockMessage'
    subscribe:  
      operationId: subscribeLock
      message:
        $ref: '#/components/messages/lockMessage'

Note That:

1. Use different operationIds (publishLock/subscribeLock) to distinguish the roles
2. Reference the same message schema for both operations since the payload is identical
3. This maintains clear separation of concerns while showing they're related operations

This approach:

• Makes the bidirectional capability explicit in the spec
• Allows tools to properly generate client code for both sending and receiving nd Maintains backward compatibility

Would this solution work for your use case? Let me know if you need any clarification or have a different pattern in mind.

[rzorzorzo]

Yes, this is how I currently solved it, having different op ids for send and receive.
However, my personal preference would have been a send-receive action, indicating that the operation can go both ways.
Please close this ticket.