zed-industries/zed · error

a window always holds at least one workspace

Error message

a window always holds at least one workspace

What it means

displayed_index() asserts the held-workspace list is non-empty because a window always has at least one workspace; the list was empty, meaning all workspaces were removed without a replacement being added — a workspace lifecycle bug.

Source

Thrown at crates/workspace/src/multi_workspace.rs:665

    }

    pub fn active_workspace_is_retained(&self) -> bool {
        self.held[self.displayed_index()].pinned
    }

    /// The displayed workspace is the most recently activated row.
    fn displayed_index(&self) -> usize {
        self.held
            .iter()
            .enumerate()
            .max_by_key(|(_, held)| held.activated_at)
            .expect("a window always holds at least one workspace")
            .0
    }

    /// Ensures a project group exists for `key`, creating one if needed.
    fn ensure_project_group_state(&mut self, key: ProjectGroupKey) {
        if key.path_list().paths().is_empty() {
            return;
        }

        if self.project_groups.iter().any(|group| group.key == key) {
            return;
        }

        self.project_groups.insert(
            0,
            ProjectGroupState {
                key,
                expanded: true,
            },
        );
    }

    /// Transitions a project group from `old_key` to `new_key`.
    ///

View on GitHub (pinned to 9d272b0363)

Solutions

  1. Ensure a workspace is always added before/when the last one is dropped
  2. Check retention logic so the final workspace is never unheld
  3. Return Option<usize> and handle the empty case
Defensive patterns

Strategy: validation

When it happens

Trigger: Thrown at crates/workspace/src/multi_workspace.rs:665 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of zed-industries/zed@9d272b0363 (2026-08-20). Data as JSON: /api/errors/e960193ea82706a5. Report an issue: GitHub.