I have one real nuisance of an intermittent long read action attributable to the following stack trace (with unnecessary frames removed to keep it semi-compact): Long read action in com.illuminatedcloud.intellij.lwc.typescript.env.AuraEnabledApexTypeDefinitionsEnvironmentUpdater.lambda$getMetadataF…

[image] Scott Wells: at com.intellij.openapi.application.ReadAction.compute(ReadAction.java:66) at com.illuminatedcloud.intellij.lwc.typescript.env.AuraEnabledApexTypeDefinitionsEnvironmentUpdater.getMetadataFiles(AuraEnabledApexTypeDefinitionsEnvironmentUpdater.java:146) This is a real pro…

If you need a blocking retryable variant of the ReadAction in a background thread you can use: ReadAction.nonBlocking { // do not forget validity check here for VFS / PSI files and Module/Project } .inSmartMode(project) // if access to indexes needed .executeSynchronously()

Thanks. I’ll give that a shot and see how it goes.

Also the rest of the stacktrace could help to understand what kind of processing you do. Is it manual/custom scanning of files? Would it be possible to share some pseudo-code of that?

That specific custom file-based index contains the qualified names of classes in my plugin’s Java-like language that have a very specific annotation denoting that they can be accessed via a JavaScript/TypeScript remoting feature. In this specific usage of the index, I need all keys because my plugi…

Do you use our indexing framework for it and plug into the platform scanning process? Or you enumerate VFS files / all keys manually in a background thread? It seems the latter.

I use the platform’s file-based index feature, specifically the fileBasedIndex EP with a subclass of ScalarIndexExtension that also implements DataIndexer, i.e.: public class AuraEnabledApexDeclarationShortNameIndex extends ScalarIndexExtension<String> implements DataIndexer<String, Void,…

To be even more specific, the code for the long-running stack trace above is effectively the following executed from a pooled background thread: Set<String> classNames = ReadAction.compute(() -> FileBasedIndex.getInstance() .getAllKeys(indexId, project) .stream() .filter(key -> !key.sta…

Oh, bingo! Then non-blocking ReadAction fits, use it for long-running processing in background, this code must also take into account dumb mode - inSmartMode(), check isDisposed of project inside read action before first access to it (once). FileBasedIndexImpl.forceUpdate() It may happen if ther…

Just to be 100% clear, you’re suggesting that I change: Set<String> classNames = ReadAction.compute(() → FileBasedIndex.getInstance().getAllKeys(indexId, project)); to: Set<String> classNames = ReadAction.nonBlocking(() -> { return project.isDisposed() ? Collections.emptySet() : …

Long read action due to FileBasedIndexImpl.ensureUpToDate() while calling FileBasedIndexEx.getAllKeys()

IntelliJ Platform

yuriy.artamonov (Yuriy Artamonov) March 10, 2026, 10:50am 13

Would like to highlight the upcoming YouTube stream where we will talk about all this