AsyncAPI: Editing a channel in source editor causes a circular reference

[GoulvenF]

Hi,

We got trouble when editing an AsyncAPI channel from the source view. The save button triggered a circular reference issue, as below:

Thanks,

[EricWittmann]

This should be resolved by Apicurio/apicurio-data-models#309

[GoulvenF]

Hi,

Thanks. We would need to have the 1.1.14 used in the studio, in order to complete the bugfix. Could you re-open ?

Best regards,

[EricWittmann]

OK I've upgraded apicurio-data-models to 1.1.14 in both pom.xml and package.json. Is there more to fixing this than that?

[DyspC]

An add command is created right there instead of a replace.

I was working on this (+ implementing cloneChannel) but I started encountering those errors https://github.com/Apicurio/apicurio-studio/runs/3402960785#step:4:21009

I don't really see anything between 1.1.13 and 1.1.14, perhaps a regression following the jsweet upgrade?

[EricWittmann]

I believe I have fixed the errors you linked to above. The workflow is still in progress so we'll know as soon as that's done. But my fix worked locally.

[DyspC]

I think there are still some runtime issues following the update, something crashes in the js bundle when I try to access the dashboard and it looks like Oas30PathItem is undefined when it needs to be extended

---

89556ef

3eac2b5

[EricWittmann]

OK I'll need to dig into this - it could be a JSweet regression. Not sure...

[EricWittmann]

I've made a little progress on this - I have confirmed that it's a JSweet regression. If I revert the JSweet and Java versions (and make no other changes) then I can load the library in the browser without issue.

I'll dig into the differences in the output from JSweet 2 to JSweet 3...

[EricWittmann]

The problem appears to be an issue I reported to JSweet last year: cincheo/jsweet#628

In that issue I mention that the only material difference I could find in the generated output is the location of some of the import statements. In the new version some of the imports were not at the top of the file, but instead at the bottom.

I've written a post-processor that will try to fix the problem by re-organizing the imports in the TS files generated by JSweet to always be at the top. But shockingly it made no difference.

Ultimately I think the problem is that we have some circular references in the data model. Specifically because OpenAPI itself has some circular references. For example:

Oas30PathItem -> Oas30Operation -> Oas30Callback -> Oas30CallbackPathItem -> Oas30PathItem

And also:

Oas30MediaType -> Oas30Encoding -> Oas30Header -> Oas30MediaType

I'm not sure why these were not problematic in JSweet 2.3.5 but they now are problematic in 3.x. I'm still trying to figure that out. Everything works (including all our Jest based tests) until the transpiled JS gets bundled using rollup. At that point the ordering of the UMD bundle (the order in which the individual .js files are bundled into the UMD) is different when using JSweet 3 vs. JSweet 2. I can't for the life of me figure out what about the generated code is different that would cause rollup to bundle it differently. It's very frustrating.

For now I'm going to revert apicurio-data-models back to Java 8 and JSweet 2.3.5 and do another release. That way we will at least have a working data models library and we can make progress on Studio again.

Aside: I think for Apicurio Data Models 2.x I'm going to need to rethink the organization of the models themselves a bit, to try and avoid circular class references. I haven't decided how that will look, but maybe more use of interfaces for the models will help.

[EricWittmann]

Releasing data models 1.1.15 now. After that I'll upgrade it in Studio and we should hopefully be able to make progress on this.

[EricWittmann]

OK this is done. Smoke tests pass. Please try this again and let's see how we're doing. :)

[DyspC]

Looks alright, I submitted the fix alongside some other things I saw while testing