Sign up
View stargazersSign up

[Bug]: GitLab project shows "Unavailable" when an open MR description pushes the list response over the 1 MB output cap#24201

opened4d agobyMmohaalak

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. Add a project backed by a GitLab repo (self-hosted GitLab, glab authenticated) that has an open merge request with a very large description. In my case it's a Renovate "update non-major dependencies" MR whose body is ~1 MB of embedded release notes (Renovate even notes "This PR body was truncated due to platform limits").
  2. Open the Pull Requests view with state = Open, involvement = All.
  3. Open Filters → Project.

Expected behavior

The project's merge requests are listed. A single oversized MR description shouldn't stop the project from being read; the list doesn't need the full description anyway.

Actual behavior

The project shows as " · Unavailable" in the Project filter, and its MRs from other authors are missing. Other GitLab projects on the same host and with the same glab auth load fine. glab mr list in the same checkout works.

Root cause, as far as I can tell from the 0.1.2 server bundle:

  • The GitLab list calls glab api projects/<path>/merge_requests?state=opened&order_by=updated_at&sort=desc&per_page=26&page=1, which returns every MR's full description.
  • For this repo that response is 1,120,446 bytes, and the Renovate MR alone is ~1,016,000 of them (12 open MRs in total).
  • VCS process output is capped at DEFAULT_MAX_OUTPUT_BYTES = 1e6, so the call fails, the project is returned in the list response's errors, and the UI marks it Unavailable.
  • Narrower queries (e.g. "Authored" by me) stay under 1 MB and still work, which makes the failure look random.

Possible fixes:

  • Raise maxOutputBytes for the MR list call (other review metadata reads already use 16 MiB), and/or
  • Request fewer items per page and paginate when the payload is large, and/or
  • Leave out or truncate descriptions in list responses, since the list view doesn't need them.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Beta) 0.1.2, macOS (Darwin 25.5)

Environment

macOS desktop app, self-hosted GitLab, glab CLI over HTTPS API