The id of a converted DiagramDescription/NodeDescription/etc. depend on its index in the View model, which is not stable

[pcdavid]

In ViewDiagramDescriptionConverter.convert(RepresentationDescription, AQLInterpreter) when we convert a View-based DiagramDescription into an actual Java DiagramDescription, we do this:

String diagramDescriptionURI = EcoreUtil.getURI(viewDiagramDescription).toString();
return DiagramDescription.newDiagramDescription(UUID.nameUUIDFromBytes(diagramDescriptionURI.getBytes()).toString())

i.e. the id of the resulting DiagramDescription is based on the View model element's URI... which includes its index. Something like sirius:///d79a46d4-272b-49f9-b1a5-747f778853ea#//@descriptions.1. This index is not stable.

1. Create a View model with two diagram descriptions D1 and D2 (they can be empty).
2. In another project, create an instance of D2.
3. Go back in the View model, and delete D1. It was not used anywhere so this should not have any impact.
4. Try to reopen the instance of D2:

java.lang.NullPointerException: null
    at java.base/java.util.Objects.requireNonNull(Objects.java:221) ~[na:na]
    at org.eclipse.sirius.components.collaborative.diagrams.DiagramContext.update(DiagramContext.java:53) ~[sirius-components-collaborative-diagrams-2022.9.8.jar:2022.9.8]
    at org.eclipse.sirius.components.collaborative.diagrams.DiagramEventProcessor.<init>(DiagramEventProcessor.java:89) ~[sirius-components-collaborative-diagrams-2022.9.8.jar:2022.9.8]
    at org.eclipse.sirius.components.collaborative.diagrams.DiagramEventProcessorFactory.createRepresentationEventProcessor(DiagramEventProcessorFactory.java:82) ~[sirius-components-collaborative-diagrams-2022.9.8.jar:2022.9.8]

Indeed, we try to find the diagram description for D2, but it does not exist anymore at the expected id. Because we re-convert the current version of the View model on-demand, DynamicRepresentationDescriptionService.findDynamicRepresentationDescriptions(IEditingContext) will return, for the same D2 description, a Java DiagramDescription with a different id.

Note that in this particular case the id we search for does not exist anymore. I think it is also possible (though I have not tested) for a diagram to "change its nature", for example if in the View model I had a D3 after D2. Once D1 is removed, D3 "steals" the id previously used by D2. Re-opening an existing D2 instance would transform it into a D3...

[pcdavid]

Note that this does not only concern the representation descriptions, but also all the elements inside, e.g. the different NodeDescription inside a particular diagram.

[gdaniel]

:+1: