One important detail: you mentioned a “GitLab project using webhooks, not using the Cursor GitLab integration.” BugBot for GitLab needs to be set up through the Cursor Dashboard (Integrations tab > Connect GitLab), not via manual webhooks. Manual webhooks alone won’t give BugBot the access it needs to complete reviews.
GitLab instance
We are using GitLab.com, not a self-hosted instance.
GitLab plan
We are on a paid GitLab plan.
Cursor Dashboard integration
Yes, we have already connected GitLab through Cursor Dashboard → Integrations → Connect GitLab.
Current configuration
The project has a Cursor webhook configured that sends events to the Cursor GitLab webhook endpoint, with push events, merge request events, issues, comments, and emoji events enabled. SSL verification is also enabled.
This exact setup is already working correctly in several of our other GitLab projects, which is why the behavior in this particular repository is unexpected.
Please let us know if there is anything specific about this repository that could prevent BugBot from accessing it or if there are additional checks we should perform.
Thanks for the detailed follow-up. Since the setup looks correct and everything works in your other repos, this seems like a repo-specific issue on our side.
A couple quick things to check or confirm before I escalate:
Is BugBot explicitly enabled for this specific repo in the Dashboard > Bugbot tab? Sometimes after syncing repos, a new repo needs to be enabled manually.
Is this MR created from a branch within the same project, or from a fork?
Is there anything noticeably different about this repo compared to the working ones, like visibility settings, repo size, subgroups, or special characters in the project path?
Once you confirm the above, I’ll pass this to the team to investigate.
Bugbot is explicitly enabled for this repository in the Dashboard → Bugbot tab. I enabled it after syncing repositories, but the issue still occurs.
The merge request is created from a branch within the same project (not from a fork). It is the initial commit.
I don’t see any significant differences between this repository and the others where Bugbot works. The repository uses our standard project settings. The only notable detail is that the project name contains a - character.
Please let me know if there’s anything else I should check or provide to help diagnose the issue.
Since the setup looks fine and it works normally in your other repos, it seems like we need to investigate this on our side.
No ETA yet, but we’re tracking your report. I’ll update this thread as soon as we have news.
One quick thing while we wait, could you try creating a second MR in this same repo, even a very simple one, and run BugBot there? I want to confirm the issue reliably reproduces in this repo and isn’t something specific to that one MR.
We’ve opened another MR and tried running BugBot there, but we have the same issue in this MR as well:
Something went wrong. Try again by commenting “Cursor review” or “bugbot run”, or contact support (requestId: serverGenReqId_a91ea74a-454f-4d5f-9298-ed50473cf2f6).
Thanks for checking it on the second MR, that confirms the issue is repo-specific.
Quick question: can you share the full GitLab path to the project in the group/subgroup/project-name format? You mentioned there’s a hyphen in the name, and I want to make sure parsing isn’t breaking on our side. This will help speed up the investigation.
I’ll update the thread as soon as I hear back from the team.
Hey, thanks for your patience, we’ve figured out the cause.
GitLab is returning null in diff_refs.base_sha for your MRs. Bugbot uses this value to find the common ancestor between branches and compute the diff. When it’s empty, Bugbot crashes instead of showing an error. This can happen when the MR was just created, the branches don’t share history, or GitLab hasn’t finished calculating the merge ref yet.
Workaround: rebase or re-push the MR branch. After that, GitLab will recalculate diff_refs, and Bugbot should run normally on the next attempt.
This is a bug on our side, we should handle this case properly. The team is aware, but there’s no timeline yet.
