✅ Deploy Preview for docs-rometools ready!

Name	Link
🔨 Latest commit	e585e2f
🔍 Latest deploy log	https://app.netlify.com/sites/docs-rometools/deploys/635bc462b7b83c000885bca6
😎 Deploy Preview	https://deploy-preview-3533--docs-rometools.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Interestingly while this does have the intended effect of reloading the configuration, this does not actually restart the server process, it's only closing the existing connection to the server and opening a new one. Because we don't currently persist or share workspace instances across sessions it goes through the whole initialization and loading of the configuration again, but it be useful to stop an old version of the Rome server to stop and start a new instance from the latest version.

How would you recommend implementing such a command. Issue the stop command right before calling into restart?

Interestingly while this does have the intended effect of reloading the configuration, this does not actually restart the server process, it's only closing the existing connection to the server and opening a new one. Because we don't currently persist or share workspace instances across sessions it goes through the whole initialization and loading of the configuration again, but it be useful to stop an old version of the Rome server to stop and start a new instance from the latest version.

How would you recommend implementing such a command. Issue the stop command right before calling into restart?

Unfortunately sending the stop command will cause the server to exit immediately while the client is still active, so the server will be immediately restarted by the auto-restart behavior of the default error handler in the client library. Ideally we would be able to call client.stop() in a way that doesn't cause it to dispose of the connection to the server so that we could issue the rome/stop request once the state of the extension has been fully cleaned up but that's not something the client library allows by default. We would either have to wrap the connection object we return to the client to prevent it from being closed while the client is being stopped, or re-implement the default error handler in our own code so we could inhibit the auto-restart behavior while we send the stop request.

@leops That sounds significantly more complicated.

Do you agree that the current solution addresses the problem where a user restarts the rome server to clear any client-specific state? And thus, merging it would improve the user experience?

I was about to say the same thing that Leo said. This PR doesn't solve the real problem.

merging it would improve the user experience?

For example, if the user updates the rome binary inside the package.json, using this command won't solve the issue. So we are on square one. We could merge it, although we still need to tell the user what are our limitations.

I planned to have a section called Known limitations in the README.md of the extension, you can see it here: https://github.com/rome/tools/pull/3526/files#diff-26e0392cd342e5ae4128c6f6bb669e6326537400604fb0a843332a2293f5cdb9

Do you agree that the current solution addresses the problem where a user restarts the rome server to clear any client-specific state? And thus, merging it would improve the user experience?

I think it's still worth it to merge this change, and we could also point the user to the rome stop command in the meantime