asyncapi: adding tags on operation and operation trait is broken

[ben-lc]

Expected Behavior

When an asyncapi document is edited, setting a tag on operation or operation traits should save the tag and allow to continue editing.

Actual Behavior

When tag is set, TypeError: e.accept is not a function will be thrown at any further ui action and broke the ui.

Steps to Reproduce the Problem

1. Create a new asyncapi spec
2. Create a new operation or operation trait
3. Set a tag
4. Try any other action

Specifications

• apicurio studio: 0.2.62.Final
• apicurio data models: 1.1.27

Cause

In info-section.component.ts when changeTags method is called after a tag is added, createChangePropertyCommand is used to update the tags property with a string array as new property. But expected type for tags property is List<Tag> in apicurio-data-models as required by asyncapi spec, so the AaiTraverser#traverseOperationBase will get a string instead of Tag node and throw the exception when trying to visit.

[ben-lc]

Hi @EricWittmann,
to solve this issue I guess a new Command that accepts Tag properties and a node path should be created. I see that there is a NewTagCommand / DeleteTagCommand that statically works on Document node with the tags-section component. Should I create a ChangeTagsCommand with a constructor for AaiOperationBase and AaiMessageBase (even if ui doesn't currently allow to set tags on message) to work with inline-array-editor, or do you have another recommandation ?

Since inline-array-editor only accepts array of string as model, and it would disallow user to edit description of tags on operation / message. Maybe adapting the tags-section component to work on operation / message should be better. Then it should require to add NewTagCommand / DeleteTagCommand for asyncapi operation / message too.

wdyt?

[EricWittmann]

I see - so looking at the specifications, the issue is that in OpenAPI an operation has a tags property with type [string] (list of strings). But in AsyncAPI an operation has a tags property with type [Tag] (list of Tag objects).

So I think the right thing to do is to either clone or adapt the existing Tags section for the main form for use in other locations.

The code in the OpenAPI editor is this:

 <tags-section [document]="document"></tags-section>

So we just need to change that component so it takes something else besides the document. Or alternatively just clone that component and have it take an asyncapi Operation.

Don't be too afraid to just brute-force this, since we're going to be rewriting the entire editor in React at some point anyway.

[ben-lc]

Hi @EricWittmann, I created Apicurio/apicurio-data-models#824 to add required commands to handle tags on asyncapi OperationBase and MessageBase commands. When it's ok, you could publish version 1.1.28 like we discussed.

I almost finished the PR for apicurio-studio to adapt the tags-section for operation and message based nodes.

[EricWittmann]

Hi @ben-lc thanks for the work.

Unfortunately we have a problem in this repository right now. The JSweet project seems to be in a bit of a bad state. The infrastructure it uses is all down (including a repository that is required because it contains dependencies not available in maven central). Check this out:

cincheo/jsweet#764

Without JSweet we cannot build or release apicurio-data-models. You'll notice that CI is failing for all the pending PRs.

I have not yet tried to address this, as I have other priorities.

I would have been happy to merge your changes and release, but cannot do so without figuring out a workaround.

If you have any time to explore options, I'd be happy for the help. If not I'll need to find time to work on this sometime in the future.

[ben-lc]

As a workaround to fix this offline repo issue, I created PR Apicurio/apicurio-data-models#826, to use a local maven repo to get artifacts sourcemap-builder-1.0.0.jar and typescript.java-ts.core-1.4.0.1.jar required by 1.x branch.
I don't really see any other alternative.

[ben-lc]

Hi @EricWittmann, do you have any feedback on my solution ?

[EricWittmann]

Sorry for the delay (as always). I like this as a temporary solution. I've merged it, and will try porting it to main as well.

FYI we are considering forking JSweet into the Apicurio org as a longer term solution.

[EricWittmann]

Release 1.1.28 is in progress. It's been awhile since a 1.1.x release was done, be patient as I expect it to fail. :)

[EricWittmann]

Done! https://www.npmjs.com/package/@apicurio/data-models/v/1.1.28

[ben-lc]

Great thanks.