Shouldn't we remove messageId in v3?

[derberg]

So in v3 under channel you need to provide a list of messages ad s key/value, where key is unique messageId

What is the use case for still having messageId in a Message Object then?

From current description, messageId on Message Object level is to Unique string used to identify the message so like it was before v3. But when I'm sharing messages across documents, I think better to treat key of the message under channel messages as unique identifier.

wdyt?

cc @dalelane that reviewed #827 with me
cc @fmvilas as contributor
cc @jonaslagoni as release coordinator

[jonaslagoni]

I stand pretty firm not to alter v3 at all.

[fmvilas]

Let's take the opportunity and remove it now. Otherwise, we would have to deprecate it and carry it until v4. I say not to complicate our lives in v3 with messageId. If we see a use case for it afterward, we add it back (maybe with a different name to avoid confusion). Adding is easy.

[derberg]

@jonaslagoni @smoya can you folks confirm how complicated will that be (removal of messageId now) from parser perspective. In latest parser, what is considered to be messageId?

Spec says below, and it is in case of Messages under a Channel.

There is one problem if we remove messageId from Message object. That if someone uses AsyncAPI as a collection of messages, without channels, they do not have a way to assign a unique messageId

[smoya]

What is the use case for still having messageId in a Message Object then?

Considering the following doc:

asyncapi: '3.0.0'
info:
  title: Test
  version: 1.0.0
channels:
  userSignedUp:
    address: 'user/signedup'
    messages:
      one:
        $ref: '#/components/messages/userSignedUp'
      two:
        $ref: '#/components/messages/userSignedUpWithExpandedData'
components:
  messages:
    userSignedUp:
      messageId: userSignedUp
      payload:
        type: object
        properties:
          username:
            type: string
    userSignedUpWithExpandedData:
      messageId: detailedUserSignedUp
      payload:
        type: object
        properties:
          username:
            type: string
          address:
            type: string
          phone:
            type: number

Prior to removing messageId, the id for those messages will be the one on that field, fallbacking to other options (See next point I'm commenting).
However, what would be the expected message id for the messages under the channel if we remove the messageId field?
one or two will be, even though they are pointing to #/components/messages/{userSignedUp|userSignedUpWithExpandedData}.
Would you then consider channel one is different from userSignedUp one just because the key on that messages map is different?

@jonaslagoni @smoya can you folks confirm how complicated will that be (removal of messageId now) from parser perspective. In latest parser, what is considered to be messageId?

I don't think it is hard. However, this is the current logic:

id(): string {
    return this.messageId() || this._meta.id || this.extensions().get(xParserMessageName)?.value<string>() as string;
}

Source: https://github.com/asyncapi/parser-js/blob/3582d31d61fde2c04d79b168102965fd405f1069/src/models/v3/message-trait.ts#L17-L19

Note that this._meta.id is the key on the key/val map if exists (I think always in the case of v3).

[jonaslagoni]

Just another breaking changes, which of course will cause break stuff here and there 😄

[Tenischev]

This double messageId identifier actually makes a bit of mess, but I would support @smoya point about potentially different messageId in channel object and in message object or even different messageId for the same message object in different channel objects.
For me as template maintainer and from programming point of view, it's more logical to rely on messageId in the message object to name the object (by means of programming language). Why I should name the object different (by messageId from channel object) if it's the same object underneath?
So, I would create an object (by means of programming language) with name from messageId in the message object and MAY BE create an empty extensions objects (by means of programming language) which will simply inherit original object with names from messageId in channel object.

Also, the point I would like to highlight, that Operation Object doesn't have a map and simply use the list of message objects which is nice and do not make any disruption.

[fmvilas]

Following Sergio's example:

asyncapi: '3.0.0'
info:
  title: Test
  version: 1.0.0
channels:
  userSignedUp:
    address: 'user/signedup'
    messages:
      one:
        $ref: '#/components/messages/userSignedUp'
      two:
        $ref: '#/components/messages/userSignedUpWithExpandedData'
components:
  messages:
    userSignedUp:
      messageId: userSignedUp
      payload:
        type: object
        properties:
          username:
            type: string
    userSignedUpWithExpandedData:
      messageId: detailedUserSignedUp
      payload:
        type: object
        properties:
          username:
            type: string
          address:
            type: string
          phone:
            type: number

Just want to remark that being able to set the message ID in place by one or two can also be a great feature. It lets you add IDs that are custom to your document and make sure it doesn't change when the referenced message changes, which may be on a external file/url.

And also would love to remind that for code generation purposes, we have the name property already.

So yeah, I'm all in for removing messageId.

[fmvilas]

BTW, I'm picking up this issue and I commit to have it done by next week.

[fmvilas]

PR for the spec: #984. Will follow up with PRs for parser-js and JSON Schemas.

[fmvilas]

So here's the full list of PRs:

• Spec: feat!: remove messageId from Message and MessageTraits objects #984
• JSON Schemas: feat!: remove messageId from Message and MessageTrait objects spec-json-schemas#439
• Parser JS: feat!: remove messageId() parser-js#889
• Parser API: feat!: remove messageId() from the Message and MessageTrait objects parser-api#102
• Converter JS: feat: remove messageId when converting to 3.0.0 converter-js#202

[fmvilas]

Added the PR to fix the converter to the list above.

[fmvilas]

I'm closing this issue as it's been addressed already. Thanks for the fast reviews and support 🙏

[WaleedAshraf]

Eh, I missed this conversation.

messageId was really useful for tooling. It was added here: asyncapi/parser-js#414

The main difference between messageId and name was the messageId was to be machine-readable and unique across the complete document.