fix: resolve DAP stack frame source off EDT

[mobiletoly]

Title
SlowOperations warning on EDT when rendering DAP stack frames (DAPStackFrame.getSourcePosition uses VFS lookup)

Summary
When debugging with LSP4IJ DAP, the IDE logs a SlowOperations warning because DAPStackFrame.getSourcePosition() performs a synchronous VfsUtil.findFile(...) lookup on the EDT during
frame list rendering. This is triggered by the XDebugger UI and happens even in normal debugging workflows.

Exception

  SEVERE - #c.i.u.SlowOperations - Slow operations are prohibited on EDT
  ...
  at com.intellij.openapi.vfs.VfsUtil.findFile(VfsUtil.java:202)
  at com.redhat.devtools.lsp4ij.dap.client.DAPStackFrame.doGetSourcePosition(DAPStackFrame.java:106)
  at com.redhat.devtools.lsp4ij.dap.client.DAPStackFrame.getSourcePosition(DAPStackFrame.java:84)
  ...

Root cause
DAPStackFrame.doGetSourcePosition() calls VfsUtil.findFile(...) on the EDT when resolving file‑backed stack frames, which triggers SlowOperations warnings.

Fix
I've moved the file lookup off the EDT and cache the result, refreshing the debug views once the source position is resolved. This avoids EDT slow ops while preserving behavior.

How it’s fixed

• If on EDT, schedule a background read action to resolve VfsUtil.findFile(...)
• Cache XSourcePosition once resolved
• Refresh debug views after resolution

Environment

• IntelliJ IDEA 2024.2.x
• LSP4IJ plugin
• Debugging via DAP

With this fix and locally installed plugin - I don't see this exception anymore

[angelozerr]

@mobiletoly thanks so much for your PR.

The thing which is annoying with your PR is that you call session.rebuildView which could be expansive.

I noticed that VfsUtil.findFile(filePath, true); which can be slow. I wonder of using LocalFileSystem.findFileByPath could improve the performance?

Could you try just to replace VfsUtil.findFile(filePath, true); with LocalFileSystem.findFileByPath and tell me if it avoids having this slow warning?

[mobiletoly]

Hey, thanks for the notes. I think I get what you're pointing out. Right now I’m calling session.rebuildView, which can be pretty heavy, and I'm also using VfsUtil.findFile(filePath, true) which might be triggering a refresh/slow VFS path.

I'll try swapping it to LocalFileSystem.getInstance().findFileByPath(...) and see if that gets rid of the warning without changing behavior. If we do need a refresh for some cases, I'll move it off the UI thread instead of doing it inline.

I'll send a follow-up PR with these tweaks so it's easy to review.

[angelozerr]

Hey, thanks for the notes. I think I get what you're pointing out. Right now I’m calling session.rebuildView, which can be pretty heavy, and I'm also using VfsUtil.findFile(filePath, true) which might be triggering a refresh/slow VFS path.

I'll try swapping it to LocalFileSystem.getInstance().findFileByPath(...) and see if that gets rid of the warning without changing behavior. If we do need a refresh for some cases, I'll move it off the UI thread instead of doing it inline.

I'll send a follow-up PR with these tweaks so it's easy to review.

@mobiletoly I will try with LocalFileSystem.getInstance().findFileByPath(...) and if it is working I will merge it and recreate a nighty build in order to you test it because in my case I cannot reproduce this slow warning.

Which dap server are you using?

[mobiletoly]

I use Delve (dlv dap)

I think I have my local fix working, but if you want to take from here, it is great. Thank you!

[angelozerr]

I think I have my local fix working, but if you want to take from here, it is great. Thank you!

You mean that you have just replaced VfsUtil with LocalFileSystem and it is working?

If it that it is super great and please create the PR (as new PR).

[mobiletoly]

new PR is here:

#1410