🐛VSCode extension stuck at 100% cpu usage

[jpike88]

Environment information

same Rome rage as here

https://github.com/rome/tools/issues/4182#issuecomment-1410177376

too big to paste in this issue creation page for some reason

What happened?

After working for a while, saving a file gets stuck and these kinds of messages appear, spinning indefinitely:

If I look at how Rome is doing in the activity monitor, it's stuck spinning at 100% like so:

Seems like there's an infinite loop issue happening? Not sure what else it could be.

If I just dismiss the dialogs, I notice that the Rome process continues to be maxed out, looks like it's stuck. Only way to stop is either close vscode or kill the process directly.

Expected result

Rome not cause CPU to max out at 100% forever!

Code of Conduct

• I agree to follow Rome's Code of Conduct

[jpike88]

@Conaclos @ematipico this is becoming a real pain to deal with, it's really hampering our continued ability to use this.

latest Rome rage attached

CLI:
  Version:              11.0.0-nightly.97e48b4
  Color support:        true

Platform:
  CPU Architecture:     aarch64
  OS:                   macos

Environment:
  ROME_LOG_DIR:         unset
  NO_COLOR:             unset
  TERM:                 "xterm-256color"
  JS_RUNTIME_VERSION:   "v16.14.2"
  JS_RUNTIME_NAME:      "node"
  NODE_PACKAGE_MANAGER: "npm/9.1.1"

Rome Configuration:
  Status:               Loaded successfully
  Formatter disabled:   true
  Linter disabled:      false

Workspace:
  Open Documents:       0

Discovering running Rome servers...

Running Rome Server: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ℹ The client isn't connected to any server but rage discovered this running Rome server.

[unvalley]

sorry #4220 may cause this problem, @Conaclos @ematipico could you revert that once?
I suspect this function uses recursive: https://github.com/rome/tools/pull/4220/files#diff-c7e026db5551c56a2d889fc340f6dad25cf7cee4a1bf6b1b199a93e30ce9fd48R171

[Conaclos]

@unvalley This seems unlikely to cause the issue. The last nightly was released two weeks ago.

Why do you think it is caused by this rule?

[unvalley]

@Conaclos oh sorry, I thought it was the latest version of the commit.

[ematipico]

Hi @jpike88 ,

We need your help to triage this issue.

You would need to find a way to reproduce the issue consistently. This issue might be around some code/file.

When you see that the Rome process goes crazy, you would need to give us the logs of the LSP server, preferably around the time the issue occurred. And the output trace in the VSCode extension.

You would need to give us the configuration you're using.

Sorry for the request, this is what we need from you to help. If you're able to create a repository, that would be awesome! Thank you

[jpike88]

is there a way I can just run it with some sort of profiling enabled and have the logs dump as they happen? I wouldn't have the slightest clue how to reproduce it, it tends to happen once I've been working for a while and I have a monorepo with a few TS project scattered throughout it, I work in the one vscode workspace.

[ematipico]

We don't have any profiling for now.

Thing is, this might be a combination of project/files/code/LSP, so it's really difficult for us help you, unless there's a deterministic way to understand the root of the issue.

You can navigate the logs of the LSP server: https://rustdocs.rome.tools/rome_cli/index.html#logs

[jpike88]

Ok good news, I can get it to stall on a particular file I have. But Rome and Rome Trace panels in VSCode tell me nothing. What next?

[jpike88]

More useful info: if I run rome check or rome ci on that same file, it runs fine and doesn't get stuck. This seems to be specific to the language server implementation.

[jpike88]

OK so looks like it was't one file in particular, it just decides at some arbitrary point to start playing up. Rome output terminal says nothing:

[cli-stdout] data 84
[cli] exit 0
Connecting to "/var/folders/0v/w61lqyb97l37zrp46x8s24900000gn/T/rome-socket-11.0.0-nightly.97e48b4" ...
[Info  - 14:18:32] Server initialized with PID: 84108

and Rome Trace is empty. But definitely only a problem limited to VSCode and not the CLI tool.

[jpike88]

This happens when I try to just quit VSCode, whatever Rome's doing it's also blocking VSCode. Terminating the Rome process directly allows VSCode to quit properly, only other alternative is for VSCode to crash.

[jpike88]

it just decides at some arbitrary point to start playing up

This is wrong, turns out it occurs on particaruly sensitive files. Whatever it's doing seems to be dependent on the file I'm trying to save.

But paste this file is either Rome tools playground, or trying via CLI works fine.

[ematipico]

Great, we have some info.

It could be that documents are not synchronized anymore, of your VSCode has some configuration that uses Rome (maybe organized imports?)

Feel free to create a repo or provide the logs once you're able to replicate the issue.

[jpike88]

There are no logs, if there was anything worth providing I'd do it but as I said the log output for the Rome and Rome Trace outputs are practically empty.

What Rome needs is a proper debug mode that can spit out enough debug messages that it's useful to begin with, or even better spit out some kind of profiler or stack analyser that would allow you to generate a flame graph or something like that. Otherwise would be exceptionally difficult for me to try and create a reproducible case with this as it isn't happening in a predicable pattern.

[jpike88]

Sorry I just realised I had to change trace to verbose in vscode settings for the extension. I'll see what it spits out

[jpike88]

traceoutput.json.zip

[jpike88]

I have a file isolated with the problem (kind of) but prefer to send it to you privately. Let me know the best way

[denbezrukov]

I'd like to investigate this issue since I'm trying to fix an utf encoding problem, maybe it can be relative.

[jpike88]

@denbezrukov I am happy to send you the file I mentioned privately, it's has a non-trivial amount of code in it

[jpike88]

I'm also able to freeze the Rome playground with my example as well

[denbezrukov]

@jpike88 Is it possible to send it on Discord?

[jpike88]

Sure, what's your username

[denbezrukov]

 @jpike88
 Denis Bezrukov#0630
https://discord.gg/rome

[jpike88]

Since updating to latest nightly, I feel like this problem might be getting worse since it's happening on a file I don't remember having problems with previously. It's becoming extremely frustrating to use the Rome extension and I'm considering just disabling it. Is there any progress on figuring this out?

[denbezrukov]

I'm still tackling problem with unicode.
If anyone wants to help with this problem, that would be great.

[ematipico]

@jpike88 we're aware of the issue, there's no need to pressure.

We're just a bunch of volunteers trying to make the best out of it.

This behaviour is extremely unhelpful

[jpike88]

Oh? I thought Rome is funded?

[jpike88]

I don't mean to pressure. I appreciate the work you guys are doing, and will just bear with it. If I could code in Rust I would have contributed already especially to fixing this problem as it is quite acute.

[ematipico]

Oh? I thought Rome is funded?

It was, yes. You can check discord for more info https://discord.com/channels/678763474494423051/678763474930761739/1068580995219083346

[jpike88]

Oh wow I didn't know! I'm sorry to hear about it.

Despite the situation I'm sticking with it, even with the current issues it's still a breath of fresh air to eslint, I could never go back. I'm certain you guys will find a continuing uptake of both funding and contributors in the meantime, don't lose hope, it's too good to ignore. I'm both happy it's in rust to maximise performance, not so happy I can't just jump in to make contributions so fast! Maybe it's time to brush up on some Rust...

[denbezrukov]

Potentially #4308 could fix the problem.

[jpike88]

great, ill jump on next nightly as soon as it's out to confirm

[jpike88]

Just tried on rome@11.0.0-nightly.763fd98 released yesterday, problem still persists.

[denbezrukov]

Could you please record a video and send it to me on Discord🙏🏼

[jpike88]

done

[jpike88]

Just an update, @denbezrukov was able to reproduce my problem with the sample code I sent. Will be interesting to see what the cause was!

[KaHLK]

What is the status of this?

I currently experience this on a few of the files in the project I'm working on.
I thing the two new issues #4422 and #4461 is the same as this, as the messages and logs they've described is exactly the same errors I get.
Due to this issue not being updated since March, I decided to do a bit of debugging myself (I've only done some basic print debugging so take it for what it is), and I think the issue is the call to similar. It seems that rome gets stuck when trying to calculate the diff of the file here. It seems that similar recommends setting a deadline when diffing two large files (as seen here), so that might be what is required to fix this issue (haven't looked into it closer).

Hope some of my findings will be helpful 🙂

[ematipico]

@KaHLK thank you very much for the information, that definitely helps a lot!

The main problem is reproducing the issue. If there's a way to create a minimal repo, that will help to debug! Without that, it's really difficult to understand the issue.