MetaCache doesn't handle node removal during load

[phreed]

Performing some deletions on a model causes a disconnect to the server.
The error was "duplicate name on meta level".
To replicate the problem.
Keep an eye on the 'In-Sync/Ahead' indicator.

• Import the attached model
• Remove the 'FCO B' object (the 'In-Sync' changes to 'Ahead 1)
• Remove the 'FCO B' object again (it disappears and 'Ahead 2')

guest+orphan_objects_master (2).json.txt

[phreed]

This model was created explicitly to expose a bug, just not this bug.
Specifically, it endeavours to introduce objects that can only be distinguished by their guid.
I would expect that any bugs that it exposes are due to using something other than guid (or equivalently path) being used to uniquely identify objects.

[pmeijer]

webgme-client-dump.json.txt

[phreed]

What version should I check to see if this is fixed?
It still has issues on https://webgme.org

[kecso]

Could you describe you issue?
I've re-checked the scenario that was corrected under this issue and it works (editor.webgme.org @ 1.7.0)

[phreed]

The error no longer occurs.
Now there is a warning.

1. Import the *.json file provided.
   orphan_objects.json.txt
2. delete the top "FCO B"
3. Get notifications of "Duplicate name on META level : FCO [A B]"

The message is correct so maybe this is not a bug?

I understand this is a different problem (feel free to open a new issue) with the same project.
As mentioned before, this project was created to test corner cases, apparently it does that.

[kecso]

I do see the problem now.
It is a different one but probably surfaced after the correction (not a direct consequence but related).
In your example I get the following result after the removal of the top 'FCO B':

• the other 'FCO B' and 'FCO BC' remained visible in the editor
• if I would try to reload it, an empty box would appear at the place of 'FCO BC'

This is a faulty behavior, and will be corrected.
On the other hand, the model itself is correct and the following workaround should be functional:

• after the removal of the top 'FCO B' try to update any node (move around a bit)
• that should enforce the loading of the nodes, and thus the removals

Please clarify if the workaround is acceptable for now?
We will push the correction into the next available release. (and I will probably move the discussion under a new issue number, so it can have a decent description of the problem)

[phreed]

Yes, this sounds right.
The work around looks good.