GohashId was missing but then a duplicate id was generated, resulting in bug

GoJS
1

Hi,

I just spend a long time trying to figure out why one of my customer’s diagram wasn’t rendering correctly (1 group was missing despite it being in the model)

I finally detected that the gohashid of the group was missing. GoJS then seems to generate a gohashID, but this newly generated gohasid already exists on a node in my model, the double occurances of the gohashid means the group is not rendered. Considering this is an internal id and i have no control over it, i would like this know how this became possible to occur. I’m just trying to better understand the chain of events that may lead to this situation, in order to prevent it in the future.

What situation would this be possible? Some race condition? a page crash that still triggers a model save with corrupt info? i would have no idea. This only occured once in the months i’ve been using GoJS.
On every change in the model, i trigger an auto save, which exports the model to a database.
i noticed that some elements in this model do not have a gohashId, while others do. Is this causing issues? should i remove these before storing, will loading a model with gohashids already in it be taken into account or are they always regenerated? trying to figure out what went wrong.

Any way to reset a model (keeping the data, resetting all gohashIds?)

2

I suspect that the main problem is that you have any __gohashid in your model data at all. Certainly Model.toJson never produces such property values. Are you doing your own serialization?

I would suggest that you remove all __gohashid properties. It really is an internal identifier used by go.Set and go.Map, which were implemented before the ES Set and Map existed.

3

I indeed do not store the model as-is but modify the structure a bit.
this exporting was looping over model.nodeDataArray as is, without any toJSON calls.
I will first export toJSON to get rid of any internal stuff. Thanks

4

As documented at Model | GoJS API, Model.toJson doesn’t write any non-enumerable properties nor any properties whose name starts with “_”. That allows apps to store non-serialized information on each data object, such as references to Objects that are not serializable.

Other characteristics of model serialization are documented in that method too.