Bugbot couldn't run on self-hosted GitLab

Support Bug Reports
,
1

One of the four repos of my self-host GitLab cannot trigger Bugbot recently. The other repos works better, but still some PRs never get feedback after emoji. Here are some of the failed request id:

serverGenReqId_5869befc-21ea-4191-b0e7-da863ffeeddf
serverGenReqId_47968313-96ca-4da5-8783-b7caea673fd7
serverGenReqId_e0e2e91c-0ed8-46b2-af10-0aa8378e4119
serverGenReqId_46adf2f9-5c64-4c4e-ba01-022f46b90181
serverGenReqId_68cc6159-5df3-4ed9-899f-e72683e42c61
serverGenReqId_d2b8d2b8-c174-4191-a78a-8ea91a08c233

All of above failed several hours after the manual triggers. The support robot Sam said it cannot trace the ids. Could you please help with this? Thank you.
No webhook error. Already fresh GitLab connection. Incremental review enabled. IP whitelist set.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey @Haoze, thanks for the report and for including the request IDs!

It looks like each run got as far as downloading the merge request’s code from your GitLab server, and that download was cut off before it finished.

From our side it looks like your GitLab server (or a proxy, WAF or load balancer in front of it) closes the connection partway through sending the repository data, after 7 to 30+ minutes of transfer. Bugbot retries a few times, which is why the “couldn’t run” message only shows up hours after the emoji reaction.

We also see your server returning “413 Payload Too Large” to very small requests from us (removing the emoji reaction), which usually points to a reverse proxy with strict limits in front of GitLab.

The repo that never works is probably just the largest, so it hits those limits every time while the smaller ones only fail sometimes.

Worth checking on your side: if there’s a reverse proxy, WAF or load balancer in front of GitLab, raise its read/idle timeout and any request/response size limits for the GitLab host (the relevant requests are POSTs to .../<repo>.git/git-upload-pack). It’s also worth grepping your nginx, gitlab-workhorse and gitaly logs for git-upload-pack between 2026-09-03 07:40 and 14:00 UTC to see what terminated those connections.

Let us know what you find!

9

Hi @Colin , thanks for your reply. The suggestions really helped.

The “413 Payload Too Large” response was caused by bugbot calling the Gitlab delete-emoji API with a body. I have solved it on my side.

I also managed to fix the timeout issue by reducing the repo size-most runs now complete within 30 minutes. However, subsequent runs after commits take much longer. Could you please look into request ‘serverGenReqId_713fd990-3539-4b3c-a267-cc73771fbf72’ ? It took 4 hours to finish. Thank you.

10

Please start a new thread!