REPL stuck and requires window reload occasionally

[Limess]

Hello, thanks again for a wonderful tool.

For a while I've had the intermittent (but basically daily) issue that when I try to jack-in to a Clojure REPL Calva will hang at this step in the repl output window:

; This is the Calva evaluation results output window.
; TIPS: The keyboard shortcut `ctrl+alt+c o` shows and focuses this window
;   when connected to a REPL session.
; Please see https://calva.io/output/ for more info.
; Happy coding! ♥️

The session never hooks up and I can never interact. The status bar shows nREPL cljc/clj as normal, and attempting to jack in again does nothing to fix it.

To resolve this I have to reload the VSCode window

I can see this stacktrace pertaining to Calva in the VSCode devtools but I don't know if it's related:

 ERR Cannot read property 'fsPath' of null: TypeError: Cannot read property 'fsPath' of null
    at outputFileDir (/Users/charlie.briggs/.vscode/extensions/betterthantomorrow.calva-2.0.198/src/results-output/results-doc.ts:45:54)
    at DOC_URI (/Users/charlie.briggs/.vscode/extensions/betterthantomorrow.calva-2.0.198/src/results-output/results-doc.ts:50:32)
    at append (/Users/charlie.briggs/.vscode/extensions/betterthantomorrow.calva-2.0.198/src/results-output/results-doc.ts:254:43)
    at Object.appendPrompt (/Users/charlie.briggs/.vscode/extensions/betterthantomorrow.calva-2.0.198/src/results-output/results-doc.ts:362:5)
    at /Users/charlie.briggs/.vscode/extensions/betterthantomorrow.calva-2.0.198/src/extension.ts:51:26
    at Generator.next (<anonymous>)
    at o (/Users/charlie.briggs/.vscode/extensions/betterthantomorrow.calva-2.0.198/out/extension.js:2:982375)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Versions

Mac OS: Big Sur 11.2.3 VSCode:

Version: 1.56.2
Commit: 054a9295330880ed74ceaedda236253b4f39a335
Date: 2021-05-12T17:44:30.902Z (2 wks ago)
Electron: 12.0.4
Chrome: 89.0.4389.114
Node.js: 14.16.0
V8: 8.9.255.24-electron.0
OS: Darwin x64 20.3.0

Calva:

Name: Calva: Clojure & ClojureScript Interactive Programming
Id: betterthantomorrow.calva
Description: Integrated REPL, formatter, Paredit, and more. Powered by cider-nrepl and clojure-lsp.
Version: 2.0.198
Publisher: Better Than Tomorrow
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=betterthantomorrow.calva

[bpringe]

Thanks for reporting. Does this happen only with a certain project?

That error makes it look like there could be an issue with Calva finding the project root. It's pointing here: https://github.com/BetterThanTomorrow/calva/blob/210e8161568f97f02da59f91a3a99af332ec433b/src/results-output/results-doc.ts#L45

projectRoot is null there in your problem case.

If you create a new project with lein new, open the project folder in VS Code, and run jack-in, does it work, and consistently? If it does, I suspect there's an issue with the project structure for the cases where it doesn't work, or maybe an issue with the directory that's being opened in VS Code. In that case we need more info about the project, or better yet, a project where the issue happens for you that we can try ourselves.

[Limess]

I see this on most of my work projects - I don't think they're doing anything particularly unusual - I can share an example project.clj with :env omitted from profiles which I saw this issue today, but I don't think we have anything public to share where I've seen this issue:

(defproject signal.example-project "0.1.0-SNAPSHOT"
  :description "Do stuff"
  :url "https://github.com/signal-ai/example-project"
  :dependencies [[org.clojure/clojure "1.10.3"]

                 [com.taoensso/timbre "5.1.2"]
                 [com.fzakaria/slf4j-timbre "0.3.21"]
                 ;; route other logging through slf4j -> timbre
                 [org.slf4j/slf4j-api "1.7.30"]
                 [org.slf4j/jul-to-slf4j "1.7.30"]
                 [org.slf4j/jcl-over-slf4j "1.7.30"]
                 [org.slf4j/log4j-over-slf4j "1.7.30"]
                 [org.slf4j/osgi-over-slf4j "1.7.30"]
                 ;; explicitly depend on tools.logging to prevent transitive clashes
                 [org.clojure/tools.logging "1.1.0"]

                 [camel-snake-kebab "0.4.2"]
                 [org.clojure/data.json "2.1.0"]
                 [environ "1.2.0"]
                 [listora/again "1.0.0"]
                 [clj-time "0.15.2"]
                 [cheshire "5.10.0"]
                 [org.clojure/core.async "1.3.610"]
                 [circleci/rollcage "1.0.218"]
                 [clj-commons/iapetos "0.1.11"]
                 [io.prometheus/simpleclient_hotspot "0.10.0"]

                 ;; AWS APIs
                 ;; exclude unneeded SDKs and only pick what we use
                 ;; exclude jackson and load latest versions instead
                 [amazonica "0.3.155" :exclusions [com.amazonaws/aws-java-sdk
                                                   com.amazonaws/amazon-kinesis-client]]
                 ;; to be safe, match current amazonica AWS SDK dependencies
                 [com.amazonaws/aws-java-sdk-s3 "1.11.850"]
                 [com.amazonaws/aws-java-sdk-sns "1.11.850"]
                 [com.amazonaws/aws-java-sdk-sqs "1.11.850"]
                 [com.amazonaws/aws-java-sdk-sts "1.11.850"]
                 ;; upgrade apache httpclient from aws-sdk version to fix s3 warn
                 [org.apache.httpcomponents/httpclient "4.5.13"]

                 ;; used for optimisations in AWS SDK on JDK 11
                 [javax.xml.bind/jaxb-api "2.2.4"]

                 ;; an old jackson version is used by AWS SDK
                 [com.fasterxml.jackson.core/jackson-core "2.12.2"]
                 [com.fasterxml.jackson.core/jackson-databind "2.12.2"]]

  :main signal.example-project.main
  :repl-options {:init-ns signal.example-project.main}
  :profiles {:dev {:source-paths ["dev"]
                   :dependencies [[criterium "0.4.6"]]
                   :plugins      [[lein-environ "1.1.0"]]
                   :env          {}}

             :prod {:plugins [[lein-environ "1.1.0"]]
                    :env     {}}

             :test {:resource-paths ["test-resources"]
                    :dependencies   [[restpect "0.2.1"]

                                     [lambdaisland/kaocha "1.0.829"]
                                     [lambdaisland/kaocha-junit-xml "0.0.76"]
                                     [lambdaisland/kaocha-cloverage "1.0.75"]]}

             :uberjar {:aot          [signal.example-project.main]
                       :uberjar-name "app.jar"}}

  :java-source-paths ["java"]
  :aliases {"dev"  ["with-profile" "dev" "run"]
            "prod" ["with-profile" "prod" "run"]
            "test" ["with-profile" "dev,test" "run" "-m" "kaocha.runner"]}
  :jvm-opts ["-Xmx12g"])

and here's a file tree with temporary files/cache omitted and classnames removed:

.
├── .calva
│   └── output-window
│       └── output.calva-repl
├── .circleci
│   └── config.yml
├── .clj-kondo
│   ├── .cache
│   │   └── 2021.04.23
│   │       ├── clj
│   │       ├── cljc
│   │       └── lock
│   └── config.edn
├── .dockerignore
├── .editorconfig
├── .git
├── .gitignore
├── .lein-env
├── .lein-failures
├── .lein-repl-history
├── .lsp
│   └── sqlite.db
├── .nrepl-port
├── Dockerfile
├── Dockerfile.test
├── Makefile
├── README.md
├── conan.yaml
├── dev
│   └── user.clj
├── dev-resources
├── docker-compose-init
│   ├── localstack
│   │   └── sqs-sns.sh
│   ├── s3
│   │   ├── .minio.sys
│   │   ├── README.md
│   │   ├── dev.example-project.signal
│   │   └── test.example-project.signal
│   ├── setup-dev-environment.sh
│   └── tests
│       └── wait-for-localstack.sh
├── docker-compose.yml
├── docker-entrypoint.sh
├── perf
│   └── input.jsonl
├── project.clj
├── signal.yml
├── src
│   └── signal
│       └── example_project
│           ├── some_namespace.clj

├── test
│   └── signal
│       └── example_project
│           ├── integration
│           │   ├── some_namespace.clj
│           └── unit
│               └── some_namespace.clj
├── test-results
└── tests.edn

[bpringe]

Hmm, I don't see anything that stands out as problematic there. Please check if you have this issue with a lein new project, then:

1. If the problem exists with a new lein project, we have more digging to do into your system because this is a problem specific to your system/setup
2. If the problem does not exist with a new lein project, we know it's something with your work projects, and we can try to narrow down the issue. Maybe running Calva in dev mode and setting breakpoints would be a good idea.

[kipz]

I see this (and have always seen this) on all my deps, lein and shadow projects under Ubuntu linux. It seems to happen if the project has been open for a while without having been jacked-in.

Reloading/restarting VSCode also fixes it for me (if I jack-in relatively quickly).

[Limess]

I also believe this is related to how long the project is open without jacking in, as I tend to notice it when coming back to projects - I can't recall loading a new project and having this issue. I'll leave a new lein project over the weekend without jacking in and try it then.

[kipz]

I'll do the same on a deps project! :)

[kipz]

FWIW - I couldn't make it fail on vanilla deps/lein projects, so there is something else going on here.

[nnichols]

I experience this almost daily, and have the same OS + app versions

[bpringe]

I wonder if this is specific to Mac OS... if anyone has this issue in another OS please comment.

[bpringe]

As a workaround for now, you may want to start your repl in a separate terminal and connect to it. For a given project, you can copy the jack-in command by using the Calva command Copy Jack-in Command to Clipboard and selecting the options you would select for jack-in. Then you can paste this in a separate terminal. Each time you reload/load a VS Code window for a project you can just connect to the already running repl.

[kipz]

I wonder if this is specific to Mac OS... if anyone has this issue in another OS please comment.

Ubuntu here

[bpringe]

Ubuntu here

Oops, sorry, I missed that above.

[Peluko]

I have the same problem when using code-server (didn't try on VSCode itself).

[bpringe]

Since this doesn't happen on our systems, it's hard to debug. If anyone having the issue wants to run Calva in dev mode while they work, then when they have the problem set a breakpoint in the jack-in code and step through the code, that could help find the issue.

See here for how to run Calva in dev mode: https://github.com/BetterThanTomorrow/calva/wiki/How-to-Hack-on-Calva. It's pretty simple and you can just do all your normal work in the extension host. Here's a good place to start debugging: https://github.com/BetterThanTomorrow/calva/blob/35f1490fe0a8e43b3c19ecab37a83edf2a1973d3/src/nrepl/jack-in.ts#L236

[punit-naik]

I am facing the exact same issue! In my case I am trying to connect to an already running repl. It hangs when I try to connect but does show normal nREPL cljc/clj. It works after if I restart VSCode and connect again.

Looks like it's working only after I see the Connecting... log line. If I don't see this log line, I basically have to restart my VSCode.

I have been facing this issue for more than 4 months now.

I am running vscode on Ubuntu 20.04

[PEZ]

@punit-naik have you tried if it is enough with just reloading the window (Command Palette -> Developer: Reload Window)? Thinking it might tell us something if it really is a full VS Code restart that is needed. (No idea what it tells us, but anyway.)

[punit-naik]

@punit-naik have you tried if it is enough with just reloading the window (Command Palette -> Developer: Reload Window)? Thinking it might tell us something if it really is a full VS Code restart that is needed. (No idea what it tells us, but anyway.)

Yes, it does work if I just do Reload Window. One more thing I have noticed is that it almost never works if I have more than one running REPLs in my VSCode integrated terminal. It works fine if I have just one.

[PEZ]

So, I often have ten or more REPL servers running from my vscode terminals, but always in different windows. Are you having several servers running from the same window?

[punit-naik]

Yes, I have multiple REPLs running in the same window. But it used to work just fine, 4 months back though.

On Wed, 16 Jun 2021, 3:36 am Peter Strömberg, @.***> wrote:

So, I often have ten or more REPL servers running from my vscode terminals, but always in different windows. Are you having several servers running from the same window?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BetterThanTomorrow/calva/issues/1189#issuecomment-861867663, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWILEIX6C5WGVWP73TYUV3TS7FGHANCNFSM454XBILA .

[PEZ]

Probably something changed in VS Code. We should check their issue tracker. Very good with these hints you are providing!

Meanwhile: If generally you are connecting rather than jacking in, as a workaround you could start your REPLs in a terminal outside VS Code. It has the benefit that reloading the VS Code window will not kill the REPLs.

[PEZ]

it used to work just fine, 4 months back though.

Probably something changed in VS Code

In February this was added to the terminal feature of VS Code: https://code.visualstudio.com/updates/v1_54#_retain-terminal-processes-on-window-reload

Correlation is not causation, I know, but...

[bpringe]

This PR was released a little over 3 months ago: https://github.com/BetterThanTomorrow/calva/pull/1053. I doubt this is an issue though, but since it was a lot of refactoring (though simple replacements, really) involving state, I thought I'd mention it here.

[PEZ]

@punit-naik You can try see if #1053 has to do with this issue (I doubt it) by installing Calva v2.0.178 and seeing if the issue appears there.

Also to see if it could be the terminal reconnection feature, try with VS Code 1.53. I think this is much more likely, so I would start with this one.

[kurtharriger]

I was having this issue as well... I thought I would try switching to vscode and calva. Leiningen projects work fine but as far as I could tell I could never get a deps.edn project to connect. The terminal ouptup showed nrepl starting:

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.8.3"},cider/cider-nrepl {:mvn/version,"0.26.0"}}}'  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
WARNING: Implicit use of clojure.main with options is deprecated, use -M
nREPL server started on port 64380 on host localhost - nrepl://localhost:64380

But the calva output window would display nothing after "Happy Coding"

; This is the Calva evaluation results output window.
; TIPS: The keyboard shortcut `ctrl+alt+c o` shows and focuses this window
;   when connected to a REPL session.
; Please see https://calva.io/output/ for more info.
; Happy coding! ♥️

I would try to type a command and nothing.

I then found this issue and tried the Reload Window trick and that worked. Now I can't seem to reproduce it... and didn't think to check the console first. If I see the issue again I will try to gather more info... but here is my vscode version info

Version: 1.63.2 (Universal)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:37:28.172Z (1 wk ago)
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0

Not sure how to get calva extension version but the changelog tab shows the following

Changes to Calva.

[Unreleased]
[2.0.231] - 2021-12-14
Fix: Calva randomly edits file while in Live Share
...

I was trying to follow this xtdb tutorial when I encountered the issue and the entirety of my project consisted only of this deps.edn file copied from the tutorial. So pretty sure the issue isn't related to project structure.

{:deps
 {org.clojure/clojure {:mvn/version "1.10.0"}
  org.clojure/tools.deps.alpha
  {:git/url "https://github.com/clojure/tools.deps.alpha.git"
   :sha "f6c080bd0049211021ea59e516d1785b08302515"}
  com.xtdb/xtdb-core {:mvn/version "dev-SNAPSHOT"}} ;; "RELEASE"

  :mvn/repos
  {"snapshots" {:url "https://s01.oss.sonatype.org/content/repositories/snapshots"}}}

[kurtharriger]

OK, I was able to get a bit more information running instance of vs code from calva project.

A bit before I did try to clean my project a bit before deleting the .lsp and other folders with git clean -xdf and wondered maybe if it might be waiting on Clojure LSP before starting, but after closing and reopening the project I was able to get a repl started while Clojure LSP was still initializing, but then after reloading the project again a bit later I noticed the fsPath issue in console and was not able to start a repl.

I'm still not certain what series of steps is necessary to reproduce the issue, but here is the stack trace for the fsPath error...

I also wonder if this error might be due to Clojure LSP indexing work in background and maybe the promise rejection is what sets up the bad state... (just a theory) rejected promise not handled within 1 second: TypeError: Cannot read property 'fsPath' of null

... During my debugging, I also encountered a couple more errors which I believe are completely unrelated but I was able to capture stack trace for them while running the debug build...

and

[bpringe]

It seems that when you get that error, projectRoot is null here: https://github.com/BetterThanTomorrow/calva/blob/29c6da4954667edd724bc748ac26f3195176342c/src/results-output/results-doc.ts#L46.

Maybe if you continue to use Calva using the development build, you can troubleshoot why that is occurring.

If you do happen to find steps to consistently reproduce the issue, please post them here. Thanks for your troubleshooting, @kurtharriger!

[PEZ]

Can you share your project, @kurtharriger ?

[kurtharriger]

The project I've been primarily working on is here: https://github.com/kurtharriger/logseq-things3-query-proxy

The issue isn't entirely consistent but does seem to happen to me several times a day, often does happen when switching from one project to another. I've just sorta gotten into the habit that if repl doesn't start to reload the window and try again.

[stefan-toubia]

This looks like the same issue I found in #1509 .

https://github.com/BetterThanTomorrow/calva/blob/c46b01154a07ff5ade9f5d13265c2b7107528ff2/src/results-output/results-doc.ts#L283-L284

applyEditing is set to true before DOC_URI throws an exception, so it remains stuck in applyingEdit mode.

[bpringe]

This should be fixed via #1510.