Some calva commands become unresponsive after long-running use, until a reboot (MacOS)

[byronrthomas]

I've been scratching my head over this one for some time. Essentially my usage pattern is:

• Have several VS code windows open
• Normally one of these has a calva REPL running against the project inside it
• I keep this one live for a long while
• Sometimes I would like to either disconnect and reconnect that long-running REPL, or jack-in in another VS code window to a different project

This kind of workflow used to work fine, but recently (I have noticed this issue since around November or December) I have found that after some indeterminate amount of time / usage, Calva stops responding to commands like jack-in or doesn't respond to jack-in from another VS code window. It isn't a failure to jack-in where you see output from lein, you don't get any output at all, nor did you see the popup windows that ask you to select a profile to run with, etc. The last time it happened, it also stopped responding to the "Calva Diagnostics: Clojure-lsp server info" command (it didn't even pop up the notification toast saying that the server is unavailable or still initialising either), although I have only recently started looking at this command, so not sure how consistently that happens.

My currently active project has been doing quite a lot of logging to terminal, meaning the REPL output window can be 10k+ lines, so I thought this issue might be in play, but I'm not so convinced any more because I've tried the following:

• When things become unresponsive, close all VS code windows, ensure no VS code processes running
• In the project where I was jacked-in do rm -rf .calva && rm -rf .lsp && rm -rf .clj-kondo
• Which I believe should have removed all of the state related to my 10k+ lines of repl output, so no heavy files for LSP to chew on next time it runs
• Re-open VS code
• At this point jack-in still doesn't respond (not even popping up the menu to select a lein profile etc)
• However the Calva diagnostics works again now
• This situation has only ever been resolved by a reboot so far, after this everything is back to normal for a few hours / day

Any idea what this could be or how to diagnose / workaround it? I'm happy to help investigate / fix it if anybody has some initial pointers.

• Could it be somehow something to do with the Mac going into sleep mode?
• Any ideas what other state could be lying around that gets cleared out by a reboot?
• Are there any logs / diagnostics to keep an eye on that could help?
• Is it something to do with my working pattern - multiple windows? Surely clojure LSP & Calva should be OK with multiple VS code windows open?
• Any known issues around having multiple REPLs jacked into different projects from VS Code?

Here is the output from Calva says start-up with the versions. I am using MacOs 12.1 and VS Code Version: 1.63.2, Calva 2.0.234

Calva is utilizing cider-nrepl and clojure-lsp to create this VS Code experience.
  nREPL dependencies configured:
    nrepl: 0.9.0
    cider-nrepl: 0.27.4
    cider/piggieback: 0.5.3
  clojure-lsp version configured: latest

If you are new to Calva, please consider starting with the command:
  **Calva: Fire up the Getting Started REPL**
  https://calva.io/getting-started/

(See `showCalvaSaysOnStart` in Settings to control the auto-showing of this message panel.)

clojure-lsp version used: 2022.01.03-19.46.10
clj-kondo version used: 2021.12.20-SNAPSHOT

[bpringe]

I don't know of any issues around having multiple VS Code windows jacked in to different projects. When jack-in fails (or seems to do nothing), are you seeing a message anywhere that the command isn't found?

Some places you can try to look for information:

1. The developer console (Help -> Toggle Developer Tools -> Console tab)
2. The nrepl log. See if any messages are being sent when you try to jack-in, and if they give any clues.

I was going to suggest looking at clojure-lsp-related info, but I doubt this is related to clojure-lsp since it has nothing to do with jack-in, and should not affect it (that I'm aware).

[bpringe]

Well, in case you didn't already know hot to find this info, and for the sake of thoroughness, here's where you can find info on clojure-lsp happenings.

Another thing that could be helpful is run Calva in development mode, put a breakpoint at the beginning of the jack-in command, and use the debugger to see what could be going wrong. Maybe you can do this with a project after experiencing the issue, since it sounds like the issue will still occur until a reboot.

Here's where you could place a breakpoint:

calva/src/nrepl/jack-in.ts

Line 236 in 0877850

status.updateNeedReplUi(true);

[bpringe]

Also, when this problem occurs, have you tried starting a repl in a terminal, then connecting to it with Calva, rather than using jack-in?

[PEZ]

I see reports increasingly often about similar things. It doesn't seem to be about jack-in or the REPL, because people also report issues from pure static usage of Calva. I think this is a regression in VS Code, but I am far from sure. I have never experienced it myself, even though I most often run with 10+ windows, most of them jacked-in, for weeks upon weeks.

Might be time to mine VS Code issues a bit.

[byronrthomas]

OK, thanks for the pointers on investigation. I'll try to dig a bit further based next time, based on the info you've given here.

It's also good to know that my way of using Calva isn't too crazy / unsupported.

I'll comment back once I have more info.

[byronrthomas]

I've experienced one occasion of Calva becoming unresponsive this morning, and made a few observations, which I'll note down here. I will try and dig deeper when it next happens.

• nRepl logging is empty when Calva doesn't respond to jack-in command.
• I noticed that when Calva became unresponsive, and I tried to kill VS code, there was still a single clojure-lsp process left running, not sure whether this is a clue or not
• I tried killing clojure-lsp and restarting VS code without rebooting, but it didn't resolve the issue, I even tried this after deleting local cache files (rm -rf .calva && rm -rf .lsp && rm -rf .clj-kondo) and again it was unresponsive

I noticed something in developer tools, but this is actually being reported after a reboot too, when Calva will actually respond. I always see these warnings / errors in my dev tools console output:

TMScopeRegistry.ts:45 Overwriting grammar scope name to file mapping for scope source.clojure.
Old grammar file: file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/extensions/clojure/syntaxes/clojure.tmLanguage.json.
New grammar file: file:///Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/clojure.tmLanguage.json
register @ TMScopeRegistry.ts:45
console.ts:137 [Extension Host] Unable to log remote console arguments Output omitted for a large object that exceeds the limits
console.ts:137 [Extension Host] Starting clojure-lsp at /Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/clojure-lsp
console.ts:137 [Extension Host] rejected promise not handled within 1 second: Error: command 'resolve-macro-as' already exists
I @ console.ts:137
console.ts:137 [Extension Host] stack trace: Error: command 'resolve-macro-as' already exists	at registerCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:95:29537)	at Object.registerCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:104:21205)	at /Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2:418804	at Array.map (<anonymous>)	at /Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2:418785	at /Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2:419405	at Generator.next (<anonymous>)	at o (/Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2:414130)
I @ console.ts:137
mainThreadExtensionService.ts:63 [[object Object]]command 'resolve-macro-as' already exists
$onExtensionRuntimeError @ mainThreadExtensionService.ts:63
mainThreadExtensionService.ts:64 Error: command 'resolve-macro-as' already exists
	at registerCommand (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:95)
	at Object.registerCommand (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:104)
	at vscode-file://vscode-app/Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2
	at Array.map (<anonymous>)
	at vscode-file://vscode-app/Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2
	at vscode-file://vscode-app/Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2
	at Generator.next (<anonymous>)
	at o (vscode-file://vscode-app/Users/byron/.vscode/extensions/betterthantomorrow.calva-2.0.235/out/extension.js:2)
$onExtensionRuntimeError @ mainThreadExtensionService.ts:64

As I said the messages above appear in the console when Calva is working as well as when it is not.

I don't feel that I've seen a smoking gun yet, but I'll dig deeper the next time it happens. Just posting here now to not lose this info and in case it gives any clues.

[PEZ]

Thanks for investigating this, @byronrthomas!

I experienced something like this two days ago. Might be something completely different, but these two things happened:

1. A function I was benchmarking with Criterium started to run 4X slower. Reloading the VS Code window fixed it.
2. No output in the output/REPL window at jack-in, except the initial message. Evaluations still happened. Reloading the VS Code window did not help. Restarting VS Code helped.

VS Code had been running for several weeks, with some average of 7 or so projects opened. I'm on MacOS, Monterey.

[bpringe]

Yes, thanks for investigating, @byronrthomas! You've brought to light an unrelated issue that I made another issue for.

[PEZ]

I'll be closing this now, as we have no real clues. If someone finds more clues and also finds this issue, please re-open.