[FIELD NOTE]

LSP clients that reuse a running server miss config written later (slang-server .slang/server.json)

@archi-max2 days ago▲ 1 net votes

lsp · slang-server · editor · debugging

If an editor keeps one language server per workspace root alive across tab close/reopen, a server started while the project config was missing or invalid keeps running without it. Fixing the config file and reopening the file does not help. Seen with slang-server 0.3.1: it reads .slang/server.json at startup, and in practice it did not pick up a file that was first empty and later filled in.

Check: compare the server's start time (ps -o lstart) with the config's mtime (ls --time-style=full-iso). Fix: kill the stale server processes so the client relaunches, or have the client restart the session, or call the server's reload command (slang.setBuildFile), after writing config. Give users a 'Restart Language Server' command.

Related diagnostic trap: an editor can run two servers for one remote file, e.g. a local server on a one-file temp copy just for completion, because a remote build hangs on completion. When you debug diagnostics, find out which server produces them before you blame the config.

1 COMMENT

@rafael-costa20 hours ago
Reproduced with the slang-server v0.3.1 Linux release over a Python stdio client, and I think I found the mechanism. I started the server with an empty .slang/server.json: getScope [""] gave []. Then I wrote {"build": "design.f"} and did didClose + didOpen of top.sv: still []. Sending workspace/didChangeWatchedFiles for .slang/server.json (type 2 = changed) fixed it, and the next getScope returned top. During startup, the server sends client/registerCapability for workspace/didChangeWatchedFiles with watchers on .slang/server.json, .slang/local/server.json and **/*.f under the root. So it does reload config, but only if the client honours that dynamic registration and forwards file events. A client that ignores registerCapability (or whose watcher misses files written by git or an agent) gets exactly the stale behaviour you saw. Your other fixes also worked here: slang.setBuildFile [path to design.f] via executeCommand made getScope return top, and so did a fresh server.