# #33299 runtime transcript: Pull requests page with 180 GitLab projects

Setup (same on both sides): web dev server (`T3CODE_DEV_SEED=0 vp run dev`) on a fresh database created by
that side's own server; 180 projects added with `t3 project add`, each a local `git init` checkout whose
`origin` is a public gitlab.com project from the `gitlab-org` group (list and setup script attached);
`glab` 1.124 authenticated to gitlab.com (GitLab 19.6); a logging shim in front of `glab` (attached)
records every process. The page was opened at `/pull-requests?involvement=all&state=open`.
The web client sends three `pullRequests.list` requests on open (the list, the "authored" and the
"reviewing" partitions). Line-count reads (`pullRequests.listStats`, one per project with rows on the
page) are a separate RPC this change does not touch.

## Before: main at 1a43f4870d
Run 1 (cold):

- glab processes: 115; last finished at +32.6 s after navigation
  - other: 109
  - REST merge_requests: 5
  - viewer (api user): 1
  - failed other: 10 (error)
  - failed REST merge_requests: 5 (error)

Run 2 (reload):
- glab processes: 138; last finished at +34.3 s after navigation
  - per-project project(fullPath:): 138
  - failed per-project project(fullPath:): 39 (429)

Result: one GraphQL list read per project; gitlab.com answered part of them with HTTP 429 and
no GitLab merge request appeared on the page (only the server's own GitHub project's rows).

## After: fix/issue-33299 at d101a22235 (cold server start, same page)

Page open (navigation to +36.2 s):
- glab processes: 91
  - batched `projects(fullPaths:)` list reads: 54 (3 list requests x 18 reads of 10 projects)
  - per-project `project(fullPath:) { mergeRequests(iids:) { diffStatsSummary } }`: 37 (line counts for rows on the page, `pullRequests.listStats`, unchanged by this PR)
  - per-project list reads: 0; version probes: 0 (cached per host from the server's first read)
  - failed: 6 batched and 5 stats reads with HTTP 429, all after +33 s
- Server spans: the three `pullRequests.list` calls finished in 30.7, 30.8 and 31.0 s; every
  `GitLabPullRequestProvider.listChangeRequestsAcross` call succeeded.

Host filter (`&host=gitlab.com`, a second load later):
- glab processes: 100 (54 batched list reads, 43 stats reads, 3 other); 1 batched read timed out on
  gitlab.com and fell back for its own 10 projects only; 1 stats read got HTTP 429.
- The page lists 197 merge requests from the gitlab-org projects (screenshot attached).

Notes: gitlab.com's GraphQL request limit is about 20 s; with the full list fields 25 paths x 20 rows
took 8.5-14.7 s and sometimes timed out, 10 x 20 about 6 s, which is why reads carry 10 projects.
The 429s come from this account's GraphQL quota after an hour of probing; a self-hosted GitLab like
the reporter's has no such limit by default.