Indexing is stuck forever for a project

NoClassDefFoundError error usually indicates broken installation. Did you try re-installing from scratch? I'd also suggest removing custom plugins, configuration and caches

Hi Elena,

I removed existent version, downloaded a new one and run it. I'm using Debian so I don't really install webstorm, just run the binary - no luck. I don't really have custom plugins and I tried to restart and invalidate cache.

Maybe you can tell where Webstorm keeps the local cache so I can clean it too.

Please try removing ~/.WebStorm2019.1 folder

Nope, still the same issue.
If I open the indexing dialog, it just shows the path to the project.

In the logs I have now

2019-06-06 17:05:54,751 [ 380599] INFO - cloudConfig.CloudConfigManager - === Start.updateIO ===
2019-06-06 17:05:54,751 [ 380599] INFO - cloudConfig.CloudConfigManager - === updateIO ===
2019-06-06 17:05:54,816 [ 380664] INFO - cloudConfig.CloudConfigManager - java.security.cert.CertificateException: java.security.SignatureException: Signature does not match.
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: java.security.SignatureException: Signature does not match.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1944)
at sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1939)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1938)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1508)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)
at com.jetbrains.cloudconfig.AbstractHttpClient.download(AbstractHttpClient.java:94)
at com.jetbrains.cloudconfig.CloudConfigFileClient.list(CloudConfigFileClient.java:192)
at com.intellij.idea.cloudConfig.ETagCloudConfigFileClient.list(ETagCloudConfigFileClient.java:38)
at com.intellij.cloudConfig.CloudConfigManager.listFiles(CloudConfigManager.java:2154)
at com.intellij.cloudConfig.CloudConfigManager.lambda$updateIO$6(CloudConfigManager.java:445)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:311)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: java.security.SignatureException: Signature does not match.
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at com.jetbrains.cloudconfig.AbstractHttpClient.download(AbstractHttpClient.java:92)
... 10 more
Caused by: java.security.cert.CertificateException: java.security.SignatureException: Signature does not match.
at com.jetbrains.a.b.O.a(O.java:459)
at com.jetbrains.a.b.O.checkServerTrusted(O.java:446)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1091)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
... 23 more
Caused by: java.security.SignatureException: Signature does not match.
at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:449)
at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:392)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.jetbrains.a.b.O.a(O.java:452)
... 26 more
2019-06-06 17:05:54,818 [ 380666] INFO - cloudConfig.CloudConfigManager - === End.updateIO ===

but I'm pretty sure this is due to proxy configuration

Yes, must be a proxy issue... The error likely means that the certificate WebStorm receives in the response is not the one it expects (not from JetBrains, has different signature length). Seems the traffic between your machine and between our server is intercepted via HTTPS proxy server that caches secure traffic and replaces certificates. Please check the solutions provided at https://intellij-support.jetbrains.com/hc/en-us/articles/206544889-SignatureException-Signature-doesn-t-match-or-Signature-length-not-correct-got-256-but-was-expecting-512.

Right, thanks.

And what about the infinite indexing? Is it also related to the proxy?

No, I don't think so... Proxy error likely prevents settings synchronization (error occurs on attempt to synchronize settings with JetBrains account), but shouldn't affect indexing. Does indexing work for other project?

Yes, for all other projects indexing is working correctly

How big is your project? Do you have any symlinks in its path?

Code-wise is not that big. Maybe around 15-20 thousand lines of code.
We have symlinks to the other node_modules and bower_components. Maybe 4-5 folders. Should I remove them?

Please try it - does it make things any better?

If I remove all node_modules, than indexing works as expected. Trying to figure out now what module causes the issue

Found it!

The "figlet" package triggers the infinite indexing. This is a line to trigger the issue:
npm i figlet 

After it, Webstorm indexing won't stop.

It's not critical for me since this package is not used in the development, but still, I think the issue can be annoying at least

Thanks, logged as https://youtrack.jetbrains.com/issue/WEB-39288; please follow it for updates

You can exclude the node_modules/figlet/importable-fonts folder from indexing (Mark directoiry as/Excluded) to get rid of the issue

Awesome, thanks for the help!

Workaround: You can install versions 1.1 to avoid the infinite indexing.

Unfortunately updating to figlet 1.1 didn't help, and my entire node_modules directory is already excluded—so I don't have an option to mark node_modules/figlet/importable-fonts excluded. In fact, why is WebStorm indexing this directory at all?

>why is WebStorm indexing this directory at all

because all direct dependencies listed in package.json are added to JavaScript libraries for completion/navigation and thus indexed

I'm running into this same issue in IntelliJ with the same library. With figlet-1.2.3 it gets stuck on importable-fonts.  I see in the ticket this was fixed for WebStorm. Should it also be fixed on IntelliJ? I'm running 2019.1.4 on MacOS.

Unfortunately I don't see a way to exclude it, and it also seems to break all autocomplete.

I was able to figure out a work-around, but perhaps there's another bug. node-modules was marked as excluded, but for some reason some individual folders inside the excluded folder were marked to be included, such as figlet. I removed the exclusion of node-modules and then I was able to exclude figlet which allowed indexing to complete.

So I'm thinking there is a bug that causes some child directories in an excluded folder to be included. Unfortunately I can't share the project that reproduces it and am unable to create another project to reproduce the issue.

>I see in the ticket this was fixed for WebStorm. Should it also be fixed on IntelliJ? I'm running 2019.1.4 on MacOS.

it's fixed in 2019.2.x; please upgrade IDEA to the most recent version

> node-modules was marked as excluded, but for some reason some individual folders inside the excluded folder were marked to be included, such as figlet.

node_modules are only partially excluded, direct dependencies listed in package.json are added to javascript libraries for completion and thus included

Ah! Sorry! I thought I was on the latest version. I updated before I wrote this, but didn't realize I was two versions behind.

That seems to have fixed it, thanks!

 After an hour of looking online, i tried this and it worked

I had this issue , I excluded some folders( by right clicking a folder then  and click  Mark Direcorty as excluded from the menu)

I stashed my changes then it  immediately stoped indexing, i then un-stashed my changes .

restarting webstorm, restarting the machine , did not work.

I have had these issues for as long as I remember myself using the PhpStorm and then WebStorm (total of at least 7+ years). With a fresh install of PhpStorm/WebStorm, it never was an issue to open an existing project and let it index the files of a project (I keep all projects in a separate mounted folder, more than 50 of them) and took no longer than a minute. Then I would disable all and every xxxStorm update and keep working with that version for a few years until I have to reinstall the OS.

Thus, the best solution for me always was

- install the WebStorm on a new system

- pay for current version (or use older one I paid for previously, if its still like 2-3 years old)

- pause and prevent all and every update (!!!)

Yes, JetBrains, I am effectively saying that your regular updates unfortunately DO break my workflow. For example, it would ALWAYS
- flush all the SVN repo history for each project
- forget all secondary/popup windows positions and sizes (file compare window, FTP compare window, commit window and list goes on)

- force re-indexing (most of the times falling into indefinite loop bringing all of my work to a complete stop)

...some versions few years ago even dropped all FTP passwords (which was a pain to restore)

For those on Ubuntu, like myself, once you do a fresh OS install and a WebStorm install with snap (or you just want to revert to previous stable version of WebStorm and prevent all future updates), you could do something like

// get all currently installed versions
$ snap list webstorm  --all

Name      Version   Rev  Tracking       Publisher   Notes
webstorm  2023.1.4  327  latest/stable  jetbrains✓  classic,held
webstorm  2023.2    329  latest/stable  jetbrains✓  disabled,classic,held

// apply the rev you would like to stick with (from the result above, in this example it is the rev 327)
$ sudo snap revert webstorm  --revision 327

// pause snap updates for webstorm
$ sudo snap refresh --hold webstorm

Yes, JetBrains, I am effectively saying that your regular updates unfortunately DO break my workflow. For example, it would ALWAYS 
- flush all the SVN repo history for each project
- forget all secondary/popup windows positions and sizes (file compare window, FTP compare window, commit window and list goes on)

- force re-indexing (most of the times falling into indefinite loop bringing all of my work to a complete stop)

We're sorry for this experience with our products. We'd be happy to get more details about each problem to address each case to the appropriate member of development team and suggest workarounds.
Could you please create a a new issue in in out tracker and attach there the detailed description and your logs collected via Help | Collect Logs and Diagnostic Data. Logs may contain sensitive data like project names or file paths, so we ask you to create a new issue in our tracker where all .zip attachments are visible only to jetbrains team by default.