Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server hangs after some requests #149

Closed
kubukoz opened this issue Nov 18, 2022 · 1 comment · Fixed by #173
Closed

Server hangs after some requests #149

kubukoz opened this issue Nov 18, 2022 · 1 comment · Fixed by #173
Labels
bug Something isn't working

Comments

@kubukoz
Copy link
Owner

kubukoz commented Nov 18, 2022

Takes ~800 queries (in groups of 7) atm.

When you run many queries in a sequence, repeatedly, it shows up as a major slowdown of the editor (I haven't done a root cause analysis yet, so this isn't 100% confirmed as the culprit). I suspect TDM tracking the output panel, memorizing its length, and some other LSP commands try to parse the panel, or worse - the panel reaches the limit of a String's size and can no longer be parsed.

Anyway, TDM tracks the output panels and it probably shouldn't.

It's kinda messed up: TDM currently tracks all files, including output panels. Just removing them by virtue of ignoring them based on FileNames.isOutputPanel isn't enough, because files not found in TDM will be read from disk. Obviously, these ones can't.

I think the solution will be to apply a filter on a higher level, which will ensure that none of the LSP requests actually get to the language server logic if they're targeting an output panel. However, the RCA still needs to be done.

It's an old bug, likely as old as the LSP server migration, so #54. Frankly, it could've been an issue in JS world too.

@kubukoz kubukoz added the bug Something isn't working label Nov 18, 2022
@kubukoz kubukoz changed the title TextDocumentManager shouldn't track output panels Server hangs after some requests Nov 18, 2022
@kubukoz
Copy link
Owner Author

kubukoz commented Nov 20, 2022

I'm starting to think this is a race condition: between the configuration request in formatting and the response for it, there's a textDocument/didChange from the client. I wonder if that could be why the entire server gets blocked...

[Trace - 04:23:52 AM] Received request 'textDocument/formatting - (606)'
Params: {
  "textDocument": {
    "uri": "file:///Users/kubukoz/projects/smithy-playground-demo/use-clauses.smithyql"
  },
  "options": {
    "tabSize": 2,
    "insertSpaces": true,
    "trimTrailingWhitespace": true,
    "insertFinalNewline": true
  }
}


[Trace - 04:23:52 AM] Sending request 'workspace/configuration - (181)'
Params: {
  "items": [
    {
      "section": "smithyql.formatter.maxWidth"
    }
  ]
}


[Trace - 04:23:52 AM] Received notification 'textDocument/didChange'
Params: {
  "textDocument": {
    "version": 375,
    "uri": "file:///Users/kubukoz/projects/smithy-playground-demo/use-clauses.smithyql"
  },
  "contentChanges": [
    {
      "text": "use service playground.std#Clock\n\nuse service demo.smithy#DemoService\nuse service playground.std#Random\n\nNextUUID {\n\n}\n\nCurrentTimestamp {\n\n}"
    }
  ]
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant