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

Topic		Replies	Views
Blog post: UI Freezes and the Dangers of Non-Cancellable Read Actions in Background Threads Announcements blog	14	408	March 25, 2026
"'YourPlugin' might be slowing things down" reported when invoking the IDE's SynchronizeAction from the EDT IntelliJ Platform	12	757	January 5, 2026
How to wait for indexing to be finished in a test? IntelliJ Platform	0	57	March 1, 2026
Stub indexes and conditional compilation problems IntelliJ Platform	23	414	May 20, 2026
UI Freezes in JetBrains IDE Plugins and How to Avoid Them Announcements livestream	1	160	March 19, 2026

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

Related topics