-
Notifications
You must be signed in to change notification settings - Fork 2.1k
fix: lsp handle pidlock AlreadyOwned without failing init (fixes #10576) #10831
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
base: main
Are you sure you want to change the base?
fix: lsp handle pidlock AlreadyOwned without failing init (fixes #10576) #10831
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@AryanBagade is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
|
@anthonyshew could you please review the pr!! |
|
@anthonyshew @tknickman |
|
@anthonyshew @tknickman could you please see above comment from @AryanBagade and consider approving? would be great to have this fix, as the issue is 100% reproducible every time a new IDE window is opened. |
close #10576
Description
Fix VSCode duplicate-window LSP initialization failure by treating
PidlockError::AlreadyOwnedas non‑fatal during LSPinitialize. This allows a second VSCode window on the same repo to start normally while preserving exclusivity for optimize-only features in the first window.crates/turborepo-lsp/src/lib.rs) :- when the pidlock is already owned, log an info and continue initializing instead of returning an internal error.Screenshots
Testing Instructions
turbo.json.turbo.json.Rationale
The pidlock is used to protect exclusive “optimize” behavior. Regular LSP features (diagnostics, completion, code actions) don’t require exclusivity. Allowing secondary windows to initialize avoids user-facing failures without sacrificing the exclusivity of the first holder.
Affected Code
crates/turborepo-lsp/src/lib.rs(initialize path)Notes for Reviewers