# #33299 runtime transcript, fix head 556883c44c

Setup: web dev server (`T3CODE_DEV_SEED=0 vp run dev`) on a fresh database created by the fix
head's own server; 180 projects added with `t3 project add`, each a local `git init` checkout whose
`origin` is a public gitlab.com `gitlab-org/*` project (setup-checkouts.sh, gitlab-org-paths.txt);
`glab` 1.124 signed in to gitlab.com; glab-logging-shim.sh in front of `glab` records every process.
Same driver and project list as the "before" run on main in runtime-transcript.md.

## Load 1: /pull-requests?involvement=all&state=open (cold server)
- glab processes: 103; last one finished at +61.9 s
  - 54 batched `projects(fullPaths:)` list reads (3 list requests x 18 reads of 10 projects)
  - 47 per-project `project(fullPath:)` reads: 10 for the projects of one batched read that
    gitlab.com timed out ("Request timed out. Please try a less complex query"), the rest
    line-count stats for rows on the page (`pullRequests.listStats`, unchanged by this fix)
  - 1 version probe for the host (was one per checkout), 1 viewer read
  - failed: 1 batched read (gitlab.com timeout), 2 stats reads (HTTP 429)

## Load 2: same page with host=gitlab.com
- glab processes: 103 (54 batched list reads, 49 per-project reads); 1 batched timeout, 1 HTTP 429
- The page lists 201 merge requests from the gitlab-org projects (after-gitlab-host-556883c.png)

## Before, main at 1a43f4870d (from runtime-transcript.md, same driver)
- 138 per-project list reads in one reload, 39 answered HTTP 429; no GitLab merge request listed.

Note: on gitlab.com the wall time stays close to main's, because gitlab.com's per-row cost for
large projects such as gitlab-org/gitlab dominates and every glab call shares a server-wide limit
of 4. The process count per list drops from one per project to one per 10 projects.

## Final head 5ce423557f (each project's first page read together, continued by its own cursor)
Same database and driver, dev server restarted cold; page opened at
/pull-requests?involvement=all&state=open&host=gitlab.com.
- glab processes: 178
  - 54 batched `projects(fullPaths:)` list reads; the last finished at +62.5 s; one timed out on
    gitlab.com and its 10 projects were read on their own
  - 122 per-project `project(fullPath:)` reads: those 10 fallbacks plus line-count stats
    (`pullRequests.listStats`, one per project with rows on the page, unchanged by this fix)
  - 1 version probe for the host, 1 viewer read; per-project list reads otherwise: 0
  - failed: 1 batched read (gitlab.com timeout), 3 stats reads HTTP 429, 5 stats reads cut off
- The page lists 1301 merge requests (each project's first page) with "Load more pull requests".
- "Load more" pressed at +83.7 s, after gitlab.com had started answering HTTP 429 at +81 s: it
  spawned no glab process (the host was in rate-limit backoff), so continuation was not observed
  live. It is covered by the service test "continues GitLab projects read together by each
  project's own GraphQL cursor".

## Final head 4834744c32: first page as deep as a single-project read
The batched read now asks each project for min(limit, 100) rows (99 by default), as the
single-project read does. A live probe with the same query on gitlab.com 19.6
(probe-depth.py, authenticated glab):
- 10 projects (paths 51-60) x first 99: 5.6 s, 219 rows; same 10 x first 20: 5.4 s, 111 rows
- heaviest chunk (gitlab-org/gitlab, gitlab-runner, charts/gitlab and 7 more) x first 99:
  9.9 s, 281 rows; x first 20: 5.5 s, 114 rows
All under gitlab.com's ~20 s cutoff, with no GraphQL complexity error. The full 180-project page was
not re-run at this head (the account's GraphQL quota was exhausted by the earlier runs).