What causes "temporary repository barrier canceled" in zed-industries/zed?

Re-run the restore after reopening; the operation is restartable and did not indicate a git failure.

temporary repository barrier canceled

Error message

temporary repository barrier canceled

What it means

After building a temporary project for the restore, the code awaits Repository::barrier() so pending git operations finish before the worktree is mutated. This error means the barrier future was dropped — the producing entity or channel was released during window/project teardown — i.e. the wait was cancelled, not that git failed.

Source

Thrown at crates/agent_ui/src/thread_worktree_archive.rs:469

    let repo_path_for_find = repo_path.to_path_buf();
    let repo = temp_project
        .update(cx, |project, cx| {
            project
                .repositories(cx)
                .values()
                .find(|repo| {
                    repo.read(cx).snapshot().work_directory_abs_path.as_ref()
                        == repo_path_for_find.as_path()
                })
                .cloned()
        })
        .context("failed to resolve temporary repository handle")?;

    let barrier = repo.update(cx, |repo: &mut Repository, _cx| repo.barrier());
    barrier
        .await
        .map_err(|_| anyhow!("temporary repository barrier canceled"))?;
    Ok((repo, temp_project))
}

/// Re-adds the worktree to every affected project after a failed
/// [`remove_root`].
async fn rollback_root(root: &RootPlan, cx: &mut AsyncApp) {
    for affected in &root.affected_projects {
        let task = affected.project.update(cx, |project, cx| {
            project.create_worktree(root.root_path.clone(), true, cx)
        });
        task.await.log_err();
    }
}

/// Saves the worktree's full git state so it can be restored later.
///
/// This creates two detached commits (via [`create_archive_checkpoint`] on
/// the `GitRepository` trait) that capture the staged and unstaged state

View on GitHub (pinned to bc538def45)

Solutions

Re-run the restore after reopening; the operation is restartable and did not indicate a git failure.
In code, treat this specific error as abort and skip rollback logic that assumes a git failure.
Keep restore tasks alive (store or detach them) so teardown does not silently drop them mid-operation.

Defensive patterns

Strategy: try-catch

Try / catch

match repo.update(cx, |repo, _| repo.barrier()).await {
    Ok(_) => { /* proceed with restore */ }
    Err(_canceled) => {
        // teardown aborted the wait: skip git-failure rollback, abort quietly
    }
}
// note: the subsequent .context("failed to …") branch is the real git failure path

Prevention

Keep restore tasks alive (store or detach them) until git operations complete.
Warn or defer window close while a restore is in flight.
Make teardown idempotent so a cancelled barrier leaves no half-applied state.

When it happens

Trigger: Closing the window or dropping the temporary project/repository while the unarchive flow is still awaiting quiescence; the restore task being cancelled mid-await.

Common situations: User quits Zed or closes the window during 'Restoring thread…'; tests dropping the AsyncApp context before the await completes.

Related errors

AI-assisted analysis of zed-industries/zed@bc538def45 (2026-08-16). Data as JSON: /api/errors/8055c74701b7ea06. Report an issue: GitHub.