Add support for messageId

[WaleedAshraf]

Is your feature request related to a problem? Please describe.
Currently, there is no support for a unique identifier for messages. My use case is to use messageId for validation.

Describe the solution you'd like
We have operationId. messageId would be the exact same field for messages.

Describe alternatives you've considered
For now, I'm relying on the name field and adding extra checks on it. But it's not required to be unique by specs.

Additional context
Related slack conv: https://asyncapi.slack.com/archives/C34F2JV0U/p1604399108296600
Another previous conv about adding messageId: #94 (comment)
Related request from tooling: WaleedAshraf/asyncapi-validator#25

[derberg]

@WaleedAshraf better copy-paste the slack conversation as we are on slack free plan and it will soon be lost

[WaleedAshraf]

Yup, I also noticed that, when trying to search for an old conv.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[derberg]

@fmvilas I think we can add label that indicates this issue reached Stage 1. What do you think. @WaleedAshraf just has to open a new PR as the other one was closed some time ago, but was already approved.

@WaleedAshraf keep in mind we no longer have schema in spec repo but now it is only in https://github.com/asyncapi/asyncapi-node

to reach Stage 2 we are missing a PR on the JS Parser that enables the feature. Not everything can be done with JSON Schema. To assure uniqueness of IDs, in my opinion there needs to be a custom validation provided as we did with operationId.

[fmvilas]

Yeah, agree this one is on Stage 1. I've added the proper label.

[WaleedAshraf]

@derberg in asyncapi-node I already have a pr asyncapi/spec-json-schemas#24
Do we still need a PR here? I'm still confused about how schema changes take place.

I think we need PR against the "2021-06-release" branch.

Also, do we need to update js-parser right away? It doesn't need to be? Otherwise, we can end up with the same problem that other libs/tooling blocking newer versions of the schema.

Well, I think these things will clear out with time on how/when we rollout new version.

[derberg]

@WaleedAshraf

I think we need PR against the "2021-06-release" branch.

every PR for 2.1 release must be against 2021-06-release

Also, do we need to update js-parser right away? It doesn't need to be? Otherwise, we can end up with the same problem that other libs/tooling blocking newer versions of the schema.

To get a change in the spec it must reach Stage 3 and it requires a change (approved PR) against the release branch. Have a look at the guide

We want to have at least schema and parser supporting the latest spec as the most important tools. The others can follow up independently before or after the release.

[WaleedAshraf]

Got it. I don't think I'll have time any soon. So, I'll just leave it here for someone to pick and I can help out if needed.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[joerg-walter-de]

I am coming from me looking for a message-specific operationId.

I am used to generate client code for OpenAPI specs, that is for example callable JS functions where the function names match the operationId s and the functions provide datagram / parameter validation. And obviously it would be nice for a client to be able to call sendPing(), subscribeToData() etc. that is, to have a send-function for each possible message. Having a operationId for each message would help achieving that, I guess.

Currently operationId is bound to a channel. But since it may very well be reasonable to send multiple types of messages through the same channel and since it would be good to have a message specific send-function and a message-specific handler function for incoming messages a message-specific ID but probably even a message-specific operation ID may make sense.

With OpenAPI each path/method combination must have its own operation. There is an inbalance in the hierarchy in AsyncAPI: There is no equivalent for an operation let's say for create entry.

[smoya]

I'm moving back this to RFC 0 as there is no PR with spec edits. Also added Needs Champion label.

[smoya]

Hi @WaleedAshraf! since this RFC has been here for some time, I'm wondering if you would like to retake it and be the champion, hopefully, you have some time now.

I'm more than happy to help you moving it forward :)

[WaleedAshraf]

@smoya As I remember from the last discussion, this will require changes at multiple places and now I don't have the full context. I think you can help with defining each task as a separate issue, which can be picked up by anyone. I might be able to pick those.

[derberg]

change needs to be done in repo where JSON Schema is and proper helper function added to JS Parser. Should not be much work to do IMHO, we can help coordinate for sure.

[smoya]

@WaleedAshraf As you requested, here is the list of issues so you can track progress:

• Add support for messageId spec-json-schemas#131
• Add support for messageId  parser-js#414
• Plus the change in the spec docs in this right repository.

[dalelane]

@WaleedAshraf Would you like this one included in the 2.3 release? I know it's been quiet for a little while, but it looks like it could be do-able - I'd be happy to help if you'd like.

[WaleedAshraf]

Hi @dalelane
I don't think I'll have time anytime soon. :(

[smoya]

@WaleedAshraf We plan to release 2.4 release soon (April 2022). Do you think you will have some time for materializing this RFC?
I can help with it.

[WaleedAshraf]

@smoya Yes, I'll have some time. Let's sync on this on Slack.

[fmvilas]

Is Waleed back? 😱 🚀 🎉

[WaleedAshraf]

@smoya PR is there 🎉 . Who can review it?

[derberg]

@WaleedAshraf we also need an update to JSON Schema, you had a PR in the past asyncapi/spec-json-schemas#24 but you just need to create new against proper file and branch

[WaleedAshraf]

@derberg Yes. I will do that once the PR for parser PR is approved. As there can be more changes required and it gets delayed, etc.

[WaleedAshraf]

@derberg Here asyncapi/spec-json-schemas#195

[derberg]

I think we can move this one to Stage 2: Draft

• we have feat: add messageId property spec-json-schemas#195
• and feat: add support for messageId parser-js#510

and also solution itself makes a lot of sense and can't really be done differently.
@fmvilas @dalelane

cc @smoya

[smoya]

I guess the next step would be working on the spec repository. Are you @WaleedAshraf happy to move forward with it? Happy to help with it if needed.

[fmvilas]

Yeah, let's move it to Stage 2 👍

[smoya]

@fmvilas @derberg @dalelane All PR's are aproved. Can you check and add the RFC Stage 3 label? I can only proceed with merging after that.

[asyncapi-bot]

🎉 This issue has been resolved in version 2.4.0-2022-04-release.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[smoya]

This issue can be now closed as it got merged and released. @WaleedAshraf