Skip to content

[Bug]: GitLab Merge button fails: glab mr merge is run without --sha ("SHA must be provided when merging") #17007

Closed

Description

@LinusSkippy

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Open a thread whose project lives on a gitlab.com project that rejects merges without a head SHA (the API answers 400 SHA must be provided when merging).
  2. Have an open, mergeable merge request (detailed_merge_status: mergeable, pipeline passed, user.can_merge: true, Maintainer role).
  3. Press Merge in the pull request panel.

Expected behavior

The merge request is merged.

Actual behavior

The action fails with the generic toast:

The host refused the merge. Check that you have write access, that the checks it requires have passed, and that the branch is not conflicting.

The server runs (apps/server/src/pullRequest/GitLabPullRequestCli.ts, actionArgs / runMergeRequestAction):

glab mr merge <iid> --repo <group/project> --auto-merge=false --yes

No --sha is passed, and GitLab rejects the request. Running the same command by hand shows the real error:

ERROR
All attempts fail:
#1: PUT https://gitlab.com/api/v4/projects/<group>%2F<project>/merge_requests/<iid>/merge:
400 {message: SHA must be provided when merging}.

Adding --sha <head sha> to the same command merges successfully.

Two problems:

  1. GitLab merges don't send the head SHA. glab mr merge supports --sha, and the server already knows the MR head it displayed. Passing it fixes projects that require it, and also guarantees that only the commit the user reviewed gets merged (GitLab answers 409 if the branch moved). The same applies to enable-auto-merge.
  2. glab's stderr is dropped. The failure surfaces as GitLabCliCommandError: GitLab CLI command failed. in the trace and as the generic toast in the UI, so the actual reason (SHA must be provided when merging) is invisible. It looked like an authentication problem until reproduced by hand.

Impact

Blocks work completely

Version or commit

0.0.46-nightly.20261007.2774 (code unchanged on main @ 3143335)

Environment

T3 server on Fedora Linux arm64 (headless t3 serve), T3 Desktop on macOS as client; glab 1.121.0 authenticated via token (glab auth status OK); gitlab.com.

Logs or stack traces

VcsProcessExitError: VCS process failed in GitLabCli.execute: glab (<repo>) exited with 1 - Process exited with a non-zero status.
PullRequestOperationError: Pull request operation runAction failed: GitLab CLI command failed.

Workaround

Merge from the GitLab web UI, or run glab mr merge <iid> --auto-merge=false --yes --sha <head sha> manually.

Activity

  1. juliusmarminge commented on Oct 7, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Thanks for the detailed repro. The missing --sha on GitLab merge and auto-merge is being fixed in open PR #10946, which reads the MR's current head right before running glab mr merge and passes it with --sha, so I've linked it to close this issue when it lands. Until then, the workaround you described (merging from the GitLab UI or running glab mr merge with --sha yourself) is the way to go.

  2. AlexHoff97 commented on Oct 8, 2026

    @AlexHoff97

    Additional report on 0.0.46-nightly.20261008.2819.

    Clicking Merge in T3 Code fails with:

    The host refused the merge. Check that you have write access, that the checks it requires have passed, and that the branch is not conflicting.

    The user reports that this command succeeds:

    glab mr merge 5 --auto-merge=false --sha <current-head-sha> --yes

    Triage verified the installed release’s source at commit 5e2225671f705fcd33f1ea5591b79ba612fb6974. In apps/server/src/pullRequest/GitLabPullRequestCli.ts, actionArgs and runMergeRequestAction still invoke glab mr merge without --sha.

    This is consistent with the missing-SHA bug reported here. The underlying GitLab HTTP error was not captured for this occurrence, so the diagnosis rests on the reported successful command and source inspection.

    Environment: macOS, Darwin 27.0.0 arm64; Node v26.8.2; glab 1.113.0.

    Workaround: merge through glab with the current head SHA. PR #10946 remains open.

    Prepared by Codex (GPT-6) via t3 triage.

  3. juliusmarminge commented on Oct 19, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Fixed by #21523, which just merged to main. GitLab merge and auto-merge now read the merge request's current head right before calling glab and pass it with --sha, so projects that require the source SHA accept the merge. It rebuilds #10946 from @n0mahd. Thanks for the report!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions