Message ID doesn't exist on reply level

[AceTheCreator]

When using the request-reply pattern, and you're trying to retrieve the reply() messages, the parser is returning the wrong message ID for some reason.

Here's what I mean by wrong messages. In the example below, I expect the parser to return the messageID of the messages available in the reply object, but instead, all I get is the index(integer) of the message as ID

operations:
    requestCosting:
      action: receive
      channel: 
        $ref: '#/channels/costingRequest'
      reply:
        channel: 
          $ref: '#/channels/costingResponse'
        messages:
          - $ref: "#/components/messages/costingResponse"

cc @smoya @fmvilas

[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.

[smoya]

@AceTheCreator could you please provide a code snippet of what you are executing and the output? Thank you!

[AceTheCreator]

@smoya, here's a sample code snippet

AsyncAPI document

asyncapi: 3.0.0
info:
  title: Account Service
  version: 1.0.0
  description: This service is in charge of processing user signups
channels:
  user/signedup:
    address: user/signedup
    messages:
      subscribe.message:
        $ref: '#/components/messages/UserSignedUp'
operations:
  user/signedup.subscribe:
    action: send
    channel:
      $ref: '#/channels/user~1signedup'
    messages:
      - $ref: '#/components/messages/UserSignedUp'
    reply:
      channel:
        $ref: '#/channels/user~1signedup'
      messages:
        - $ref: '#/components/messages/UserSignedUp'
components:
  messages:
    UserSignedUp:
      payload:
        type: object
        properties:
          displayName:
            type: string
            description: Name of the user
          email:
            type: string
            format: email
            description: Email of the user

Here's the code I'm trying to retrieve the ID with

    document?.operations().filterBy((operation) => {
      if (operation.reply !== undefined) {
        const replyObj = operation.reply()
		     const messages = replyObj.messages().all();
		     messages.forEach(message => {
		       console.log(message.messageId())
                        console.log(message.id())
		     });
		   }
		});

Here's what I get in the console
undefined
0

[smoya]

Can this be somehow related to the issue under #856 @jonaslagoni ?

[jonaslagoni]

messageId is a specific value in the spec, where id comes from a more generic approach based on this.messageId() || this._meta.id || this.extensions().get(xParserMessageName)?.value<string>(). We should probably have better JSDoc for each function 👍

The 0 returned by id is because you in this case have an array of messages where this one is the first index.
undefined is returned because, well, the message object does not contain a messageId property.

Can this be somehow related to the issue under #856 @jonaslagoni ?

Not related, no 🙂

[jonaslagoni]

The 0 returned by id is because you in this case have an array of messages where this one is the first index.
undefined is returned because, well, the message object does not contain a messageId property.

Whether this behavior is the right and expected behavior, we will have to chime in @magicmatatjahu 😄 Or @fmvilas 🤔

[fmvilas]

Whether this behavior is the right and expected behavior, we will have to chime in @magicmatatjahu 😄 Or @fmvilas 🤔

I don't think it's the expected one. IMHO it should return the id of the message, most likely the one coming from the key under components/messages in this case. Or the key under a channel's messages, if $ref is pointing there.

[jonaslagoni]

The problem then is the way references are currently being handled, is NOT to replace the reference in operations to channels and messages with the already resolved object that we created for the instance in the channel.

We don't have access to the key in the key/value pair that is being referenced. Therefore the ONLY possible solution we can do is the current approach, at least with the current tooling we have at hand.

Otherwise, we have to create our own reference tooling that can resolve partial references and manually control what instance should be returned.

[derberg]

Just kind reminder that we knew that using $ref everywhere will have a side effect that it will he harder to get the id of the element and that we will have to hook into dereferencing process. So instead of waiting for or working on completely new tool that handles references, parser should grab id from the reference, and put in some extension like x-parser-refId or whatever

[smoya]

So instead of waiting for or working on completely new tool that handles references, parser should grab id from the reference, and put in some extension like x-parser-refId or whatever

It is not a trivial thing. Dereference is not handled by the parser directly but by @stoplight/json-ref-resolver (nothing new, we already knew). The fact we would need to get access to the surroundings of the referenced object in order to get the key of the map if exists makes it even harder.

[derberg]

@smoya you have the key of referenced object in the reference itself, as part of $ref string

[smoya]

Made a working POC about getting the ID from the JSON Pointer in the reference for reply.chanel and reply.messages[]: #895

Do you think it makes sense in that way? Is that what you meant @derberg ?

[derberg]

@smoya I think objectIdFromJSONPointer is complex enough that it deserves unit tests that can clearly explain what works and what doesn't work 😓

[smoya]

@smoya I think objectIdFromJSONPointer is complex enough that it deserves unit tests that can clearly explain what works and what doesn't work 😓

It is just a draft, a proof of concept. It takes the last part of the pointer as the Id.

[derberg]

sounds good to me

[jonaslagoni]

Should be solved, feel free to re-open if you still encounter it 🙂