Kirill Bulatov
49b75e9e93
Follow-up of https://github.com/zed-industries/zed/pull/34208 Closes https://github.com/zed-industries/zed/issues/35185 Previous code assumed that extensions' language server wrappers may leak only in static data (e.g. fields that were not cleared on deinit), but we seem to have a race that breaks this assumption. 1. We do clean `all_lsp_adapters` field after https://github.com/zed-industries/zed/pull/34334 and it's called for every extension that is unregistered. 2. `LspStore::maintain_workspace_config` -> `LspStore::refresh_workspace_configurations` chain is triggered independently, apparently on `ToolchainStoreEvent::ToolchainActivated` event which means somewhere behind there's potentially a Python code that gets executed to activate the toolchian, making `refresh_workspace_configurations` start timings unpredictable. 3. Seems that toolchain activation overlaps with plugin reload, as `2025-07-28T12:16:19+03:00 INFO [extension_host] extensions updated. loading 0, reloading 1, unloading 0` suggests in the issue logs. The plugin reload seem to happen faster than workspace configuration refresh in https://github.com/zed-industries/zed/blob/c65da547c9aa5d798a1a71468bf253bf55d1cb09/crates/project/src/lsp_store.rs#L7426-L7456 as the language servers are just starting and take extra time to respond to the notification. At least one of the `.clone()`d `adapter`s there is the adapter that got removed during plugin reload and has its channel closed, which causes a panic later. ---------------------------- A good fix would be to re-architect the workspace refresh approach, same as other accesses to the language server collections. One way could be to use `Weak`-based structures instead, as definitely the extension server data belongs to extension, not the `LspStore`. This is quite a large undertaking near the extension core though, so is not done yet. Currently, to stop the excessive panics, no more `.expect` is done on the channel result, as indeed, it now can be closed very dynamically. This will result in more errors (and backtraces, presumably) printed in the logs and no panics. More logging and comments are added, and workspace querying is replaced to the concurrent one: no need to wait until a previous server had processed the notification to send the same to the next one. Release Notes: - Fixed warm-related panic happening during startup
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.