ModelServer notification loop

[agonzalezgaliana]

Hi all,

currently we're testing of the connection of a Language Server and the Model Server. The Language Server is currently connected to the Model Server in 2 ways:

• To use the REST api to send edits/updates
• To use the WebSocket connection to listen to changes done in the models

we've noticed that when the Language Server sends an edit/update command to the Model Server, it immediately also receives the same change notification via WebSocket connection. We wouldn't like to have that notification back since the LS is already aware of it.

By taking a look to the ModelServer implementation it seems that this behavior is correct because there is no identification of the WS clients.

Is there something planned to avoid this unnecessary "notification loops". Do you think is something that could be adapted on our ModelServer implementation?

So far I think that each change request sent to the ModelServer could include an UUID that can be later returned as part of the change notification via WS. So the different WS client can decide whether to react on that change based on the returned UUID.

Would this be feasible?

Another question is, do other Model Server clients (i.e. Theia model server or GLSP) manage this loops?

Kind regards.

[vhemery]

I did something quite similar to avoid sending concurrent updates.
In my case, the goal was not to send any new update before the corresponding refresh occurs. So a different goal and philosphy, but in the end the same mean.

I used v4 from node-uuid lib to generate the uuid, then set a property named "commandUuid"
on the ModelServerCommand. cmd.setProperty(COMMAND_UUID_PROPERTY, uuid);
When you receive a ModelServerMessage, you should find back this uuid with

const source = modelServerMessage.data?.source;
if (source) {
    const uuid = source.properties && source.properties[COMMAND_UUID_PROPERTY];
}
// else we don't get command id in case of a full model update

So yes, you can absolutely customize it this way if you want to.
But that's up to you to handle it the way you want then.

In case it wouldn't work, this may mean I forgot about a customization I made on the model server, so please, let me know and I'll look for it. But I think that's all of it.

About the loop, there are basically 2 possible approaches for a client :

• either you just send the command to change and you wait for the notification to react to it and update your local content (the way I did)
• or you modify the local content immediately and should ignore the feedback notification (the way you are trying to)

The 1st approach works best if you expect your commands to have complex side-effects you do not fully know about in your client.
The 2nd is probably simpler if your modifications are simple and you have a good control of their scope.

[agonzalezgaliana]

Many thanks for your reply. I'll dig into the code to check what's possible and post the solution adopted.

[agonzalezgaliana]

Hi @vhemery, I've been taking a look to the Model Server code and I see that the possible solution relies on the usage of "Commands" (basically if we use the /edit REST method). However we're currently working with model creation and updates (POST/PATCH in /models REST method), sorry for the miss-wording in the original question. As far as I see, we cannot use "Commands" when changing the model using those methods.

Would it exist a similar solution for these 2 methods? From what I see the "Command" solution is pretty clean and works fine but at this moment we're not planning to forward incremental changes from the Language Server to the Model Server.

[vhemery]

IIRC, the /models REST methods make a brutal replacement of the whole resource model. So this would get you in the // else case of my previous message.
In such a case, I'm not sure you can get anything but the fact that the model has changed in your notification... The concerned model elements may even have different technical ids, which is one of the reasons I have not been using these methods.
Maybe @ndoschek or @martin-fleck-at will have more insight than me on this use case.

[ndoschek]

Yes that's true, patching the whole model can be risky. If it is possible to determine the differences from your changes, this would be the more stable way to go. If applicable, there will be JSON patch support with the ModelServer v2 version.

Besides that, adding uuids to your change requests seems like a very valuable solution if your client cannot distinguish otherwise.
Therefore you would have to adapt the Model Server itself as well to support this.
Please feel free to open a feature request if you'd like to see that general feature in the project.