Repository navigation
GitLab collection throughput: qualify complete large-project generations under a shared budget #62
Description
A bounded external GitLab probe using the existing-login CLI bridge reached its 300-second budget after 129 requests and admitted 18 detailed MR records. Collection correctly returned PARTIAL with REQUEST_OR_TIME_CAP, but a complete large-project generation is too slow for practical shared intake.
The consumer can now explicitly select registered implementations or named changes. This is a scoped inventory and must not be presented as the complete open backlog.
Follow-up acceptance:
- Measure native HTTP versus CLI bridge overhead without exporting credentials.
- Reuse a safe session or batch independent reads with one shared request/deadline budget.
- Preserve endpoint/credential cache partitioning, per-object head-race checks and explicit incomplete coverage.
- Qualify complete pagination on a large external project, repeated generations and recovery after rate/time caps.
- Never trade unknown approval/merge evidence for throughput.
This is a performance/adoption debt, not a correctness exception to the PARTIAL result.
Activity
abogun-product commentedon Oct 7, 2026
PR #69 adds shared-quota parallelism, one per-generation train inventory, deterministic material receipts and source-path failure receipts for targeted recovery. Offline regressions prove that exhausted budgets and unavailable transport responses stay explicit, with no substitution of missing evidence.
This issue remains open for bridge/native response qualification and complete repeated full generations. Detailed external deployment evidence belongs in its private adopter issue/history.