What causes "Archive progress counter thread panicked" in gitbutlerapp/gitbutler?

Re-run the dump command - transient rendering/IO conditions often clear on a second attempt

gitbutlerapp/gitbutler · error · anyhow::Error

Archive progress counter thread panicked

Error message

Archive progress counter thread panicked

What it means

The `but debug dump` archive command spawns a thread that renders progress counters while the archive is written, then joins it before persisting the file. JoinHandle::join() returning Err means that progress-counter thread panicked mid-archive; the partially written archive is then not persisted and the whole dump is reported as failed.

Source

Thrown at crates/but-debug/src/command/dump/mod.rs:106

                    repo_args.git_only,
                    diagnostics_files,
                    progress,
                )
            }
        });

        let file = ProgressWriter::new(lock, &progress);
        let mut archive = ArchiveWriter::new(file, &progress);
        if let Some(diagnostics) = &diagnostics {
            archive.add_diagnostics(diagnostics, &layout.worktree_root)?;
        }
        archive.add_repo(&repo, &layout, &output_path, repo_args.git_only)?;
        let file = archive.finish(err)?;
        let lock = file.into_inner();

        let _ = counter
            .join()
            .map_err(|_| anyhow::anyhow!("Archive progress counter thread panicked"))?;
        persist_archive(lock)?;
        Ok(())
    })?;

    writeln!(out, "Archive at: {}", output_path.path.display())?;
    open_archive_dir_unless_requested(
        &output_path.path,
        repo_args.archive.no_open_archive_directory,
    )?;
    Ok(())
}

/// Return the effective current directory selected by `-C`.
fn effective_current_dir(args: &Args) -> Result<PathBuf> {
    Ok(std::env::current_dir()?.join(&args.current_dir))
}

/// Return the default archive path for `repo`, using `suffix` after the repository name.

View on GitHub (pinned to caf1f223d3)

Solutions

Re-run the dump command - transient rendering/IO conditions often clear on a second attempt
Capture stderr: the progress thread's own panic message is printed by the default panic hook and identifies the real bug
If reproducible, report it upstream with the stderr panic; as a workaround run the dump in a plain, non-interactive shell

Defensive patterns

Strategy: retry

Try / catch

match run_dump(repo) {
    Err(err) if err.to_string().contains("progress counter thread panicked") => {
        // retry once; on repeat, keep stderr (the thread's panic message) in the report
    }
    result => result,
}

Prevention

Run `but debug dump` in a stable, non-interactive terminal when generating support archives
Always capture stderr alongside the command so thread panics are diagnosable
Keep dumps retryable: the command fails before persisting, so no partial archive is kept

When it happens

Trigger: A panic inside the progress counter thread while ArchiveWriter streams the repository - e.g. progress state invalidated by an I/O error or a rendering/formatting bug in the counter thread.

Common situations: Terminal progress rendering hitting edge cases (unusual sizes, closed or piped stdout in CI); environments where the progress thread's assumptions about the terminal break.

Related errors

AI-assisted analysis of gitbutlerapp/gitbutler@caf1f223d3 (2026-08-20). Data as JSON: /api/errors/7a00684b1ea2acda. Report an issue: GitHub.