Idle sleep prevention acquisition timed out after 10 seconds

Error message

Idle sleep prevention acquisition timed out after 10 seconds

What it means

The Linux platform waits at most 10 seconds for the display-server backend to confirm an idle-sleep prevention request via a oneshot channel, racing it against an executor timer. If the timer wins, the request is assumed stuck and this timeout error is returned instead of an ActivityGuard.

Source

Thrown at crates/gpui_linux/src/linux/platform.rs:1371

                    .await
                    .context("Failed to release idle sleep prevention")
                    .log_err();
            })
            .detach();
    })
}

#[cfg(any(feature = "wayland", feature = "x11"))]
async fn await_idle_sleep_prevention(
    guard_rx: oneshot::Receiver<Result<ActivityGuard>>,
    executor: &BackgroundExecutor,
) -> Result<ActivityGuard> {
    match futures::future::select(guard_rx, executor.timer(Duration::from_secs(10))).await {
        futures::future::Either::Left((Ok(result), _)) => result,
        futures::future::Either::Left((Err(_), _)) => {
            Err(anyhow!("Idle sleep prevention request was abandoned"))
        }
        futures::future::Either::Right(_) => Err(anyhow!(
            "Idle sleep prevention acquisition timed out after 10 seconds"
        )),
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    use gpui::{Point, px};

    #[cfg(any(feature = "wayland", feature = "x11"))]
    #[test]
    fn rejects_null_xkb_context() {
        let context = unsafe {
            // libxkbcommon permits unref on null, matching the value returned by Context::new on failure.
            xkb::Context::from_raw_ptr(std::ptr::null_mut())
        };
        let error = validate_xkb_context(context)

View on GitHub (pinned to 9d272b0363)

Solutions

Retry the request; transient compositor stalls often resolve on a second attempt.
Verify the Wayland compositor / X server is responsive (other clients behave normally).
Reconnect the display session or restart the compositor if it is wedged.
Check for suspend/resume related connection breakage in logs and reinitialize the platform if needed.

Defensive patterns

Strategy: retry

Try / catch

match platform.prevent_idle_sleep(reason).await {
    Err(e) if e.to_string().contains("timed out after 10 seconds") => {
        // check display-server health, then retry with backoff
        ensure_display_server_alive()?;
        platform.prevent_idle_sleep(reason).await?;
    }
    other => other?,
}

Prevention

Ensure the Wayland compositor / X server is responsive before long-running sessions.
Investigate suspend/resume handling if timeouts cluster after wake events.
Monitor compositor health (e.g. ping the connection) in long-lived sessions.
Retry with backoff rather than hot-looping on timeout.

When it happens

Trigger: prevent_idle_sleep's reply arrives after 10 seconds or never: the Wayland/X11 compositor is unresponsive, the inhibiting request deadlocks, or the backend thread is blocked so the guard confirmation never arrives.

Common situations: Unresponsive or heavily loaded Wayland compositor/X server; a hung display-server connection (e.g. after suspend/resume or session issues); a bug in a compositor that never answers idle-inhibit requests.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of zed-industries/zed@9d272b0363 (2026-09-12). Data as JSON: /api/errors/8155e7cf118a5540. Report an issue: GitHub.