# Pull request retry runtime evidence

Environment for both recordings: Linux x86_64, Node 26, UTC wall-clock timestamps, separately bundled T3 servers from two detached worktrees, fresh databases, synthetic project and thread. No tests, mocks, clock acceleration, or server restart during the observation. The 30× versions accelerate playback only; the original real-time videos are also supplied. The display is 1280×720 with the same dark palette on both sides.

The videos record a live display of selected real server stdout warnings, observed glab process launches, and the RPC driver's actions. They are server-output recordings, not browser or desktop screenshots. The runtime evidence JSON for each side contains exact warning blocks, command arguments and selected timing spans. CLI labels in the video summarize commands; several glab processes may belong to one synchronization attempt. Count failed synchronization warnings rather than individual glab processes to compare retry cadence.

The seed driver creates a local git repository with a gitlab.com origin, creates a project and a stopped thread using the server HTTP/WebSocket API, and manually links merge request 1 in the synthetic nonexistent project `t3code-evidence-31969/nonexistent-project`. A direct real glab request confirms HTTP 404.

Video sampling is nominally one frame per second. The top Elapsed counter counts samples and drifts by about eight seconds over the run; per-event elapsed timestamps and the supplied server/span timestamps are authoritative for retry intervals.

Both servers are left running for at least sixteen minutes. At 16 minutes 20 seconds the driver sends `pullRequests.invalidate` for the linked merge request on each side. Observation continues to minute 33 to cover the next background retry after this refresh.

`run.mjs` takes head checkout, base checkout and scratch directory as arguments; it launches the bundled servers under strace, creates its own authentication credential, seeds both sides with `driver.mjs`, records both live displays at one frame per second, and stops its servers in `finally`. Build each checkout first with `vp i` followed by `vp run --filter t3 build:bundle`. `extract.mjs` takes the timestamped output directory, base checkout and head checkout and writes public selections of the runtime logs. Private startup output and unrelated trace spans are intentionally excluded from uploads.

A synchronization sweep occurs about once a minute after the previous sweep completes. A link created just after a sweep can first retry near minute 2 because its one-minute backoff is still active at the next sweep. Read durations also shift later sweep times slightly. Recordings preserve the measured times rather than forcing the approximate 0, 1, 3, 7, 15 minute schedule.

The target is persistently nonexistent throughout this reproduction. Recovery after a successful read is not demonstrated.

AI-assisted; verified with the tests and tools listed above.

Observed result: base logged 34 failed synchronization reads in 33 minutes; head logged 7. Head failures occurred at 00:02, 02:03, 04:05, 08:07, 16:08, 16:23 (explicit refresh), and 32:09. The refresh was requested at 16:21 and the next background failure was 15 minutes 46 seconds after its failure. Both processes were stopped after the observation.