1. clojure-lsp always create a .lsp folder after a success analyze, no need to create it

well, there wasn't one here

maybe because there was one in a higher dir?

so the project was not analyzed properly by clojure-lsp, the logs or the log to client should say that

it depends on what was the project root

sent by lsp-mode (configured by user)

yes, anyway fixing that fixed the problem for me

could you confirm your project root is configured properly @nbtheduke?

if clojure-lsp doesn't scan the project properly, it will both log to clojure-lsp log and send a message to client which will print something like Classpath lookup failed....

"workspaceFolders": [
        {
            "uri": "file:///Users/noah/Personal/datalog/test/noahtheduke",
            "name": "/Users/noah/Personal/datalog/test"
        },
        {
            "uri": "file:///Users/noah/Personal/datalog/src/noahtheduke",
            "name": "/Users/noah/Personal/datalog/src"
        },
        {
            "uri": "file:///Users/noah/Personal/datalog",
            "name": "/Users/noah/Personal"
        },
        {
            "uri": "file:///Users/noah/.vim",
            "name": "/Users/noah"
        }
    ],

that’s what vim sent to clojure-lsp

hmm, lsp log:

2021-08-23T16:03:49.865Z UnknownHost INFO [clojure-lsp.source-paths:134] - Automatically resolved source-paths from deps.edn: #{"src" "resources" "test"}
2021-08-23T16:03:50.339Z UnknownHost INFO [clojure-lsp.crawler:133] - Analyzing source paths for project root /Users/noah/Personal/datalog
2021-08-23T16:03:50.346Z UnknownHost INFO [clojure-lsp.crawler:77] - Paths analyzed, took 0.006113346 secs. Caching for next startups...
2021-08-23T16:03:50.346Z UnknownHost DEBUG [clojure-lsp.server:?] - :initialize 500ms
2021-08-23T16:03:50.347Z UnknownHost INFO [clojure-lsp.kondo:64] - Linting whole project files took 1ms
2021-08-23T16:03:50.356Z UnknownHost INFO [clojure-lsp.server:350] - Initialized!
2021-08-23T16:03:50.356Z UnknownHost DEBUG [clojure-lsp.server:?] - :initialized 0ms
2021-08-23T16:03:50.361Z UnknownHost DEBUG [clojure-lsp.server:?] - :didOpen 4ms
2021-08-23T16:03:52.362Z UnknownHost DEBUG [clojure-lsp.server:?] - :semanticTokensFull 1ms
2021-08-23T16:03:55.146Z UnknownHost ERROR [clojure-lsp.server:?] -
com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine      PosixJavaThreads.java:  192
            com.oracle.svm.core.thread.JavaThreads.threadStartRoutine           JavaThreads.java:  553
                        java.util.concurrent.ForkJoinWorkerThread.run  ForkJoinWorkerThread.java:  183
                          java.util.concurrent.ForkJoinPool.runWorker          ForkJoinPool.java: 1594
                               java.util.concurrent.ForkJoinPool.scan          ForkJoinPool.java: 1656
             java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec          ForkJoinPool.java: 1020
                             java.util.concurrent.ForkJoinTask.doExec          ForkJoinTask.java:  290
              java.util.concurrent.CompletableFuture$AsyncSupply.exec     CompletableFuture.java: 1692
               java.util.concurrent.CompletableFuture$AsyncSupply.run     CompletableFuture.java: 1700
                  clojure-lsp.server.LSPTextDocumentService/reify/get                 server.clj:  139
                                       clojure-lsp.handlers/did-close               handlers.clj:   69
                        clojure-lsp.feature.file-management/did-close        file_management.clj:  180
                                     clojure-lsp.shared/uri->filename                 shared.clj:  123
                                          clojure.string/starts-with?                 string.clj:  364
java.lang.NullPointerException:

2021-08-23T16:03:55.148Z UnknownHost DEBUG [clojure-lsp.server:?] - :didClose 1ms
2021-08-23T16:03:55.216Z UnknownHost DEBUG [clojure-lsp.server:?] - :didOpen 2ms
2021-08-23T16:03:57.220Z UnknownHost DEBUG [clojure-lsp.server:?] - :semanticTokensFull 0ms

sounds like a bug on recent introduced didClose

even so, not related with your issue

is there another way to determine the project root for lsp?

yes, the serverInfo command should return a project-root-uri

clojure/serverInfo/log https://clojure-lsp.github.io/clojure-lsp/capabilities/#custom-methods

Calva and emacs already have handful commands to get that using that custom method

:project-root-uri "file:///Users/noah/Personal/datalog"

is that the correct project root ?

that’s where the deps.edn is, yeah.

could you try removing both .lsp/sqlite.db and .clj-kondo/.cache?

yes, one sec

it'd be even better if you try one after the other

try first clj-kodno/.cache

oops, did both and it seems to have resolved itself

np, is it working properly now?

yes

very strange

what I think it's the issue:

clojure-lsp call clj-kondo 3 (independent from errors) times: 1. during init, after get the project classpath, to get external analysis (jars), calling clj-kondo passing the whole classpath (excluding project source-paths) 2. during init, after 1., to analyze only project source-paths 3. after any file change, running for a single file, but not important for this isue What I suspect is that, 1. doesn't run properly, but 2. runs fine, persisting a .clj-kondo/cache with only cache for project, not containing external deps

WDYT @U04V15CAJ?

well, if you have only 2, then the above issue shouldn't have happened, since clj-kondo already has a built-in cache for clojure.test

but if 1 lints clojure.test not correctly then there will be some invalid cache analysis fo clojure.test, which is more likely to cause the issue

yeah, I think it's related with old cache or something like that if you manage to repro again, let us know @nbtheduke

it would have been interesting indeed to inspect the contents of .clj-kondo/.cache after this happened

I’ll keep an eye out and if I see it again, I’ll post it!

Thanks, it's something that happens from time to time, the first report I saw of this was on Calva back on Feb/2020! So it'd be really nice if we manage to fix it somehow