Eric Holk
36b78151ee
Fixes a user-reported bug where a thread could be missing from the sidebar even though it was still present in the metadata store and still visible in Thread History. The thread reappears in the sidebar only after the user sends a message. ### Scenario A single multi-root workspace whose roots are `[/cloud, /worktrees/zed/wt_a/zed]`, where: - `/cloud` is a standalone git repo (main == folder). - `/worktrees/zed/wt_a/zed` is a linked worktree of a separate `/zed` repo. The project group normalizes to `main_worktree_paths = [/cloud, /zed]`. A thread created in this workspace is written with `main=[/cloud, /zed], folder=[/cloud, /worktrees/zed/wt_a/zed]` and the sidebar finds it via `entries_for_main_worktree_path`. If the thread's stored `main_worktree_paths` ever drifts from the group key — e.g. a stale row loaded from the store on startup, a legacy write, or a row persisted with `main == folder` — all three existing lookups in `Sidebar::rebuild_contents` miss: 1. `entries_for_main_worktree_path([/cloud, /zed])` — the thread's stored main doesn't equal the group key. 2. `entries_for_path([/cloud, /zed])` — the thread's folder paths don't equal the group key either. 3. The linked-worktree fallback iterates the group workspaces' `linked_worktrees()` snapshots. Those yield *sibling* linked worktrees of the repo, not the workspace's own roots, so `/worktrees/zed/wt_a/zed` doesn't match. The row falls out of the sidebar entirely even though the metadata is intact and the thread's folder paths exactly equal the open workspace's roots. The store heals the stored row on the next `RootThreadUpdated` event, which is why sending a message makes the row reappear — but until then the sidebar misrepresents the state. ### Fix Add a fourth lookup to `Sidebar::rebuild_contents`: for each open workspace in the group, query the store by the workspace's own root paths. Any thread whose `folder_paths` matches an open workspace's roots belongs under that group, regardless of what its `main_worktree_paths` say. This covers the gap between stale-row load and store self-heal, matches the principle that the sidebar should reflect state that exists in a reasonable way, and is symmetric with the existing lookups (same store API, one more iterator). ### Commits 1. `sidebar: Add failing repro for thread disappearing from sidebar` — adds `test_sidebar_keeps_multi_root_thread_with_stale_main_paths` which reproduces the bug. Sets up the multi-root + linked-worktree layout, persists a thread in the stale shape, and asserts the row is still visible in the sidebar. 2. `sidebar: Show threads whose folder paths match an open workspace` — the fourth-lookup fix. 31 lines in `crates/sidebar/src/sidebar.rs`, no deletions. ### Verification - `cargo test -p sidebar`: 103 passed, 0 failed (the new test was failing before commit 2 and is passing after). - `./script/clippy -p sidebar`: clean. ### Follow-ups The three existing lookups in `rebuild_contents` are each covering a different historical shape the store can be in. A real cleanup — do a one-shot migration on reload that fills in `main_worktree_paths` for any row missing it, then retire the two legacy-shape lookups — is worth doing as a separate PR, but out of scope here. Release Notes: - Fixed an issue where agent threads could go missing from the sidebar.
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 issue)
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
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.