Conrad Irwinandmorgankrey
81df6f4af0
The crash handler models the crashing user as a fixed `UserInfo` struct of `metrics_id` and `is_staff`. That is a reasonable fit for Zed and a poor extension point in general: reporting any further piece of session state with a crash means changing this crate, and every embedder along with it. The limitation has already produced a workaround in another consumer of this crate. Wanting one field that `UserInfo` has no room for is enough to push an embedder off the IPC channel entirely, onto persisting that state beside the minidump and correlating it back at upload time. That needs an atomic write, a retention window for records whose minidump never uploads, and a cross-check so a stale record cannot be attributed to the wrong crash — none of which the existing socket would have required. This replaces the `UserInfo` message with a generic `SetTags` message carrying one or more updates. Each key is the Sentry submission field the value is uploaded under, so an application can attach its own session state and reach any part of Sentry's event schema without this crate modelling what it means. Updates merge by key, and a `None` value removes one, which is how an application withdraws state from crashes it has not produced yet. A batch is applied while holding the tag-map lock once, so a crash cannot observe part of one logical state change. `set_user_info` keeps its signature and is now shorthand for setting the two identity tags in one batch, so Zed's call site is unchanged. `upload_minidump` loses its two bespoke user blocks in favour of forwarding the map, and keeps its installation-id fallback by checking whether the session ever reported a user. Two consequences worth flagging for review. The first is that this crate now knows it reports to Sentry, where previously it emitted neutral data that `reliability.rs` translated. I think that is honest rather than regrettable — its consumers upload to Sentry, and pretending otherwise is what gave `UserInfo` a shape that fits only one of them. The alternative considered was a well-known-key mapping table in the uploader, which keeps the crate agnostic at the cost of a translation layer that can silently file a value under the wrong namespace. The second is a one-time compatibility loss. A crash is uploaded by the build that starts after it, so an upgrade always reads crash data written by the previous build. Crashes pending across this change carry `user_info` and no `tags`, and will upload without user attribution. They still parse and still upload; only the identity is dropped, for one release. A test covers that. Testing: - New unit test for batch, merge, and removal semantics, driven through `on_message` so it exercises the real wire format. - New unit test that crash data written before `tags` existed still deserializes. - `cargo test -p crashes`, `./script/clippy -p crashes -p zed`, `cargo check -p zed -p remote_server`, `cargo fmt --check`. Release Notes: - N/A --------- Co-authored-by: morgankrey <morgan@zed.dev>
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking discussion)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked.
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.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.