What causes "Review labels for forge {forge:?} are not implemented yet." in gitbutlerapp/gitbutler?

Apply labels through the forge's native API or web UI for non-GitHub reviews.

gitbutlerapp/gitbutler · error · anyhow::Error

Review labels for forge {forge:?} are not implemented yet.

Error message

Review labels for forge {forge:?} are not implemented yet.

What it means

`add_review_labels()` applies labels to a review through a per-forge dispatch and returns the resulting label set. Only GitHub is implemented (via `but_github::pr::add_labels`); GitLab, Bitbucket and Azure hit the wildcard arm and this error is returned without contacting the forge.

Source

Thrown at crates/but-forge/src/review.rs:1147

) -> Result<Vec<ForgeReviewLabel>> {
    let crate::forge::ForgeRepoInfo {
        forge, owner, repo, ..
    } = forge_repo_info;
    match forge {
        ForgeName::GitHub => {
            let preferred_account = preferred_forge_user.as_ref().and_then(|user| user.github());
            let labels = but_github::pr::add_labels(
                preferred_account,
                owner,
                repo,
                review_number,
                labels,
                storage,
            )
            .await?;
            Ok(labels.into_iter().map(Into::into).collect())
        }
        _ => Err(anyhow::anyhow!(
            "Review labels for forge {forge:?} are not implemented yet."
        )),
    }
}

/// Remove one label from a review.
pub async fn remove_review_label(
    preferred_forge_user: &Option<crate::ForgeUser>,
    forge_repo_info: &crate::forge::ForgeRepoInfo,
    review_number: usize,
    label: &str,
    storage: &but_forge_storage::Controller,
) -> Result<()> {
    let crate::forge::ForgeRepoInfo {
        forge, owner, repo, ..
    } = forge_repo_info;
    match forge {
        ForgeName::GitHub => {

View on GitHub (pinned to caf1f223d3)

Solutions

Apply labels through the forge's native API or web UI for non-GitHub reviews.
Disable the 'add labels' action unless `forge == ForgeName::GitHub`.
Implement a `but_gitlab::`/`but_bitbucket::` add-labels backend and extend the match at crates/but-forge/src/review.rs:1139-1147.

Example fix

// before
add_review_labels(&user, &info, number, &labels, &storage).await?;

// after
if !matches!(info.forge, ForgeName::GitHub) {
    return Ok(Vec::new()); // adding labels is unsupported here; skip the action
}
add_review_labels(&user, &info, number, &labels, &storage).await?;

Defensive patterns

Strategy: validation

Validate before calling

use but_forge::forge::ForgeName;

if !matches!(info.forge, ForgeName::GitHub) {
    // disable the 'apply labels' action; do not call add_review_labels
}

Type guard

fn review_labels_writable(forge: &but_forge::forge::ForgeName) -> bool {
    matches!(forge, ForgeName::GitHub)
}

Try / catch

match add_review_labels(&user, &info, number, &labels, &storage).await {
    Ok(labels) => labels,
    Err(e) if e.to_string().contains("not implemented yet") => Vec::new(),
    Err(e) => return Err(e),
}

Prevention

Gate label mutations on the forge value, not on whether another label call happened to succeed — all label arms are GitHub-only.
Show 'unsupported on this forge' in the UI rather than surfacing the raw anyhow error.
Cover per-forge label coverage in tests so newly added backends stay in sync.

When it happens

Trigger: Calling `add_review_labels` with a review on a GitLab/Bitbucket/Azure `ForgeRepoInfo` — e.g. the 'apply labels' action on a non-GitHub pull request or merge request. Note that listing labels is equally GitHub-only, so the mismatch surfaces at mutation time.

Common situations: Label pickers that let users commit label changes on any forge; automation reusing a GitHub-tested flow against GitLab MRs; SDK consumers discovering the forge-agnostic API and hitting single-forge coverage.

Related errors

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