zed-industries/zed · error
attempted to read a window that is already on the stack
Error message
attempted to read a window that is already on the stack
What it means
A reentrancy guard in App::read_window: window access uses a stack to detect recursive access, and reading a window whose handle is already on the stack panics with 'attempted to read a window that is already on the stack'. It fires when code running inside a window's context (layout, paint, or an update) synchronously re-enters the same window via read_window — reentrant access that GPUI forbids because it would alias mutable window state.
Source
Thrown at crates/gpui/src/app.rs:2885
where
T: 'static,
{
GpuiBorrow::new(handle.clone(), self)
}
fn read_entity<T, R>(&self, handle: &Entity<T>, read: impl FnOnce(&T, &App) -> R) -> R
where
T: 'static,
{
let entity = self.entities.read(handle);
read(entity, self)
}
fn update_window<T, F>(&mut self, handle: AnyWindowHandle, update: F) -> Result<T>
where
F: FnOnce(AnyView, &mut Window, &mut App) -> T,
{
self.update_window_id(handle.id, update)
}
fn with_window<R>(
&mut self,
entity_id: EntityId,
f: impl FnOnce(&mut Window, &mut App) -> R,
) -> Option<R> {
App::with_window(self, entity_id, f)
}
fn read_window<T, R>(
&self,
window: &WindowHandle<T>,
read: impl FnOnce(Entity<T>, &App) -> R,
) -> Result<R>
where
T: 'static,
{View on GitHub (pinned to 9d272b0363)
Solutions
- Check whether the window is already on the stack (or pass the live &mut Window down) instead of re-entering via the handle
- Defer the read with cx.defer/spawn so it runs after the current window access completes
- Restructure callers to take Window as a parameter through the call chain rather than re-fetching it
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at crates/gpui/src/app.rs:2850 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/2e9f04c321218725.
Report an issue: GitHub.