Opening a GitLab merge request fetched both its detail and project merge settings, then fetched the same detail again for checks. In the real web app, detail and checks spawned three glab processes within about one second, spending the shared GitLab request budget.
Cache successful project merge settings for 15 minutes and merge request reads for 60 seconds, with bounded caches keyed by checkout and repository. Detail and checks share reads. Writes and explicit or post-turn refreshes clear MR reads before service cache revisions change. Execution-time permission checks remain fresh.
Fixes https://github.com/pingdotgg/t3code/issues/24190
GitCafe: https://git.cafe/pingdotgg/t3code/issues/24190
Triaged bug via the automated issue flow. This fixes the reported GitLab read duplication; other providers and the wire contract are unchanged.
3 instead of 1 and MR reads 2 instead of 1. Red command output.vp test run packages/source-control-gitlab passed 116 tests; vp test run apps/server/src/pullRequest/PullRequestService.test.ts passed 89 tests. Includes fresh permission changes, cache expiry, write invalidation and Deferred-controlled refresh races. Green command output.Server-only evidence; no render paths changed, so the visual fixture matrix is empty.
| Real app sequence | Before | After |
|---|---|---|
| Detail then immediate checks | Two detail subprocesses plus one checks subprocess | One MR read and one project-settings read; immediate checks adds none. Cold identity lookup is separately reported. |
| Checks after 20 seconds | Not sampled separately | No additional subprocesses |
| Detail after 65 seconds | Not sampled separately | One MR read; settings reused; immediate checks adds none |
| Explicit refresh | Not sampled separately | Fresh MR read immediately; settings reused |
Baseline runtime transcript · Final runtime transcript · Evidence and uploaded drivers · Test evidence index.
Verified on Linux through the real dev web app and authenticated GitLab CLI. A transient glab exit 1 during the first expiry attempt is retained in the evidence; the recovery and a separate clean expiry cycle succeeded. Baseline subprocess spans lack endpoint arguments; final evidence includes sanitized endpoint samples. No client-specific behavior changed.
Models and harnesses: Claude Opus 5.5 through Claude Code for tests and implementation; GPT-6.1-Sol through Codex for issue lead and proof; both for independent reviews, orchestrated through T3 Code.
Added 4 commits
Verdict: Approved at 3631d87
Macroscope's review found this PR approvable — This focused GitLab fix deduplicates merge-request and project-settings reads with bounded TTL caches while preserving fresh permission checks and clearing cached reads around writes and refreshes. The added service hook and tests keep the behavior contained to the existing pull-request flow.
You can add or adjust custom eligibility rules. Learn more.
✅ Thread transfer remains within every enforced ceiling.
| Provider | Metric | Main baseline | This PR | Impact | PR ceiling | |
|---|---|---|---|---|---|---|
| Codex | Total thread wire | 5.0 KiB | 5.0 KiB | 0 B (0.0%) | 6.8 KiB | ✅ |
| Codex | Thread snapshot wire | 3.8 KiB | 3.8 KiB | 0 B (0.0%) | 4.9 KiB | ✅ |
| Codex | Live turn WebSocket wire | 1.2 KiB | 1.2 KiB | 0 B (0.0%) | 2.0 KiB | ✅ |
| Codex | Live turn WebSocket decoded | 20.9 KiB | 20.9 KiB | 0 B (0.0%) | 29.3 KiB | ✅ |
| Codex | Live turn messages | 2 | 2 | 0 (0.0%) | 8 | ✅ |
| Claude | Total thread wire | 5.0 KiB | 5.0 KiB | 0 B (0.0%) | 6.8 KiB | ✅ |
| Claude | Thread snapshot wire | 3.8 KiB | 3.8 KiB | 0 B (0.0%) | 4.9 KiB | ✅ |
| Claude | Live turn WebSocket wire | 1.2 KiB | 1.2 KiB | 0 B (0.0%) | 2.0 KiB | ✅ |
| Claude | Live turn WebSocket decoded | 21.2 KiB | 21.2 KiB | 0 B (0.0%) | 29.3 KiB | ✅ |
| Claude | Live turn messages | 2 | 2 | 0 (0.0%) | 8 | ✅ |
Baseline: 27e0c68 · PR result: 3631d87 · Source CI: success
10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.
No actionable comments were generated in the recent review.
e513eb20-9b87-4539-809a-6fe9d9852287Reviewing files that changed from the base of the PR and between 27e0c684c585f955252d65f06206dd11a143bff5 and 3631d874a15bad86a5aa209441210ece421b79f8.
apps/server/src/pullRequest/PullRequestService.test.tsapps/server/src/pullRequest/PullRequestService.tspackages/source-control-core/src/server/PullRequestProvider.tspackages/source-control-gitlab/src/server/GitLabPullRequestProvider.test.tspackages/source-control-gitlab/src/server/GitLabPullRequestProvider.tsIncluded review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.
The GitLab provider now caches merge-request details and project merge capabilities. Provider writes and pull-request service refresh operations invalidate cached reads. Tests cover cache reuse, expiration, scoped invalidation, and reads during refresh.
Changes: GitLab read cache
| Layer / File(s) | Summary |
|---|---|
Provider cache and invalidation packages/source-control-core/src/server/PullRequestProvider.ts, packages/source-control-gitlab/src/server/GitLabPullRequestProvider.ts, packages/source-control-gitlab/src/server/GitLabPullRequestProvider.test.ts | The provider API adds optional read invalidation. GitLab caches detail and project capability reads, invalidates detail entries around writes, and tests cache reuse, expiration, and invalidation. |
Service refresh invalidation apps/server/src/pullRequest/PullRequestService.ts, apps/server/src/pullRequest/PullRequestService.test.ts | The service forwards scoped or global invalidations to providers during refresh. Tests verify invalidation calls and check that reads during refresh do not retain stale details. |
Priority: External image Low
Estimated code review effort: 3 (Moderate) | ~25 minutes
Change: Bug fix · Severity of issue fixed: Low
Suggested reviewers: t3dotgg, macroscopeapp
3631dNo substantiated merge-blocking issue remains; merge after normal checks.
| Check name | Status | Explanation |
|---|---|---|
| Title check | Passed | The title is concise, follows the repository's conventional commit style, and clearly describes the main change: sharing GitLab merge request reads across detail and checks. |
| Description check | Passed | The description covers the problem, change, scope and approval, and verification. It includes focused test results, runtime evidence, known limitations, and tool details. |
| Linked Issues check | Passed | Issue #24190 has two active coding objectives. GitLabPullRequestProvider caches successful project merge capabilities for 15 minutes and merge-request details for 60 seconds. The detail cache is key… |
| Out of Scope Changes check | Passed | The changes stay within issue #24190 and its stated area. The core provider interface and PullRequestService changes add the invalidation hook required to clear provider-held GitLab reads during wri… |
Explanation
Issue #24190 has two active coding objectives. GitLabPullRequestProvider caches successful project merge capabilities for 15 minutes and merge-request details for 60 seconds. The detail cache is keyed by checkout, repository, and number. getChangeRequestChecks uses the same detail cache as getChangeRequest, so detail, checks, and the sync read path can share the read. Writes and refresh invalidation clear cached reads. getViewerPermissions reads directly, which preserves fresh execution-time permission checks. Added tests cover cache reuse, expiry, checkout isolation, write invalidation, scoped invalidation, and permission freshness. The proposed rate-limit-header follow-up is not required by the issue.
Explanation
The changes stay within issue #24190 and its stated area. The core provider interface and PullRequestService changes add the invalidation hook required to clear provider-held GitLab reads during writes and refreshes. The GitLab implementation and focused regression tests support the cache behavior. No unrelated provider, client render path, or wire-contract change is shown in the supplied change summary.
Comment @coderabbitai help to get the list of available commands.