<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> `GET /api/v4/projects/:id/repository/branches` returns an empty JSON array `[]` for every page beyond page 1, even though the pagination headers on the same response correctly describe a much larger result set (`X-Total`, `X-Total-Pages`, `X-Page`, `X-Next-Page`, and a `Link` header with valid `prev`/`next`/`first`/`last` URLs). Server-side `search=` on the same endpoint continues to work, so this appears to be a defect specific to offset pagination on this endpoint. ### Steps to reproduce <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> 1. Create a project on gitlab.com and populate it with enough branches to span multiple 100-item pages. The following one-liner creates 1,350 branches on top of `main` for a total of 1,351 — matching the counts used in the logs below: ```bash git clone --depth=1 <repo-url> repo && cd repo base=$(git rev-parse HEAD) for i in $(seq 1 1350); do name=$(printf 'test-branch/%04d' "$i") git update-ref "refs/heads/$name" "$base" done git for-each-ref --format='%(refname)' refs/heads/test-branch \ | xargs -n 100 git push --atomic origin ``` 2. Request page 1 with a token that has `read_api` scope: ```bash curl -sD- -H "PRIVATE-TOKEN: $TOKEN" \ 'https://gitlab.com/api/v4/projects/<id>/repository/branches?per_page=100&page=1' ``` Observe 100 branches in the body, plus headers such as `x-total: 1351`, `x-total-pages: 14`. 3. Request page 2 (or any page 2 through last): ```bash curl -sD- -H "PRIVATE-TOKEN: $TOKEN" \ 'https://gitlab.com/api/v4/projects/<id>/repository/branches?per_page=100&page=2' ``` 4. Observe the body is `[]` (2 bytes) while the response headers still report the full count and a valid `Link` header pointing at prev/next pages. Variations that make no difference (all still return `[]` for page 2+): - Adding `id=<project-id>` to the query string (as GitLab's own `Link` headers do). - Setting `order_by=name`, `order_by=updated_asc`, `order_by=updated_desc`, `order_by=name_asc`, or `order_by=name_desc`. - Passing `sort=asc` — this is rejected with `{"error":"sort does not have a valid value"}`, so `sort` appears unsupported on this endpoint. Variation that **does** work: - `?search=<term>` returns matching branches regardless of their alphabetical position (e.g. `search=test-branch/0500` returns that branch on a repo where page 5 of the unfiltered listing is `[]`). ### Example Project <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> No shared project needed — the repro is self-contained via the shell snippet above, and reproduces on any gitlab.com project with enough branches to span multiple 100-item pages. ### What is the current *bug* behavior? <!-- Describe what actually happens. --> Page 1 returns 100 branches. Pages 2 through last all return `[]` (empty array, 2 bytes) with HTTP 200, despite the response headers on those same requests indicating that many more branches exist and providing valid navigation links. The `ETag` on the empty responses is `W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"`, which is the standard Rack ETag for a JSON `[]` body — the API layer is genuinely emitting `[]`, not something lost in transit. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> Pages 2 through last should return the corresponding slice of branches (e.g. positions 101–200 on page 2, etc.), matching what the `X-Total` / `X-Total-Pages` headers on those same responses describe. ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> Response headers for `GET /api/v4/projects/<id>/repository/branches?per_page=100&page=10` on a repo with 1,351 branches (project ID redacted; correlation ID for this specific capture is in the "Correlation IDs" section below): ``` HTTP/2 200 Link: <https://gitlab.com/api/v4/projects/<id>/repository/branches?id=<id>&page=9&per_page=100>; rel="prev", <https://gitlab.com/api/v4/projects/<id>/repository/branches?id=<id>&page=11&per_page=100>; rel="next", <https://gitlab.com/api/v4/projects/<id>/repository/branches?id=<id>&page=1&per_page=100>; rel="first", <https://gitlab.com/api/v4/projects/<id>/repository/branches?id=<id>&page=14&per_page=100>; rel="last" ETag: W/"4f53cda18c2baa0c0354bb5f9a3ecbe5" Cache-Control: must-revalidate, max-age=0, private Content-Type: application/json Content-Length: 2 gitlab-lb: haproxy-main-16-lb-gprd gitlab-sv: api-gke-us-east1-b x-gitlab-score-gitaly: 12 x-next-page: 11 x-page: 10 x-per-page: 100 x-prev-page: 9 x-runtime: 0.627310 x-total: 1351 x-total-pages: 14 ``` Body: ``` [] ``` Same test, scripted across multiple pages of the same repo: | page | body size | branches returned | | ---: | ---: | ---: | | 1 | 79 775 | 100 | | 2 | 2 | 0 | | 5 | 2 | 0 | | 10 | 2 | 0 | | 13 | 2 | 0 | | 14 | 2 | 0 | | 15 | 2 | 0 | ### Correlation IDs Captured 2026-07-06 17:04 UTC against gitlab.com; well within log retention. `X-Total: 1351` on every request. | page | outcome | content-length | ETag | x-request-id / correlation_id | |---:|---|---:|---|---| | 1 | 100 branches | 79 775 | `W/"2694617971f3ebb1e2dcee6e0ffbe899"` | `a170308f88fe6aa8-MAN` | | 2 | `[]` (bug) | 2 | `W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"` | `a17030955fed3c84-MAN` | | 5 | `[]` (bug) | 2 | `W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"` | `a170309b0cee2a45-MAN` | | 10 | `[]` (bug) | 2 | `W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"` | `a170309fdb01b37e-MAN` | | 14 | `[]` (bug) | 2 | `W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"` | `a17030a55983b3d8-MAN` | Note that the four `[]` responses all share the identical weak ETag `4f53cda18c2baa0c0354bb5f9a3ecbe5` (Rack's canonical value for a JSON `[]` body), while the successful page-1 response has a distinct ETag matching its actual content — confirming the empty pages are being generated as `[]` at the API layer, not stripped in transit or by any intermediary cache. ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> This bug happens on GitLab.com <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> Not familiar enough with the codebase to point at a line, but the observation that pagination *metadata* (totals, prev/next links) is calculated correctly while the *body* is empty suggests the count query and the data query for this endpoint are diverging — for example, the data query may be applying an implicit `LIMIT/OFFSET` that resolves to no rows while the count query uses a separate path. `search=` bypassing the issue is consistent with that: the search path likely doesn't go through the same offset computation. <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->