Repository navigation
[git-sim] idx196/197/199: create_pull_request run-quota (max 1) blocks parallel fan-out #51690
Description
Git Simulator Finding
Scenario ID: tiny-shallow-single-small-diverged-multi / tiny-shallow-single-small-diverged-merge_msg / tiny-shallow-single-medium-clean-multi (cell indices 196, 197, 199)
Safe Output Tested: create-pull-request (and push-to-pull-request-branch for the diverged cells)
Outcome: rejected / error / rejected
Run Date: 2026-08-10
Run ID: 31356809302
Systemic Root Cause (not a per-cell git-size finding)
This run fanned out 4 parallel sub-agents (idx196–199), each independently attempting the safe outputs required by its BRANCH dimension (all non-error branch modes call create_pull_request as their first step, per this workflow's own Phase 2 design). Only one of the four (tiny-shallow-single-medium-clean-single, idx198) succeeded. The other three all failed identically:
Error [-32602]: calling "tools/call": E002: create_pull_request limit reached — 1 of 1 already used this run
push_to_pull_request_branch for the diverged cells then failed for a second, independent reason: with safe-outputs.push-to-pull-request-branch.target: '*', the tool requires an explicit repo and pull_request_number. Since create_pull_request never produced a PR number for these cells, no legitimate pull_request_number was available, and the sub-agents correctly declined to fabricate one.
This is a run-level create_pull_request quota of 1, not a per-cell git-cost boundary. It will reproduce identically for any future batch of ≥2 cells in the same run that require a fresh create_pull_request call, regardless of SIZE/HISTORY/FILES/PATCH/COMMIT — i.e., it is orthogonal to the entire configuration space this simulator is exploring.
Configuration Matrix Cells Affected
| Dimension | idx196 | idx197 | idx199 |
|---|---|---|---|
| SIZE | tiny (0 files) | tiny (0 files) | tiny (0 files) |
| HISTORY | shallow (5 entries) | shallow (5 entries) | shallow (5 entries) |
| FILES | single (1 file) | single (1 file) | single (1 file) |
| PATCH | small (50 KB) | small (50 KB) | medium (200 KB) |
| BRANCH | diverged | diverged | clean |
| COMMIT | multi | merge_msg | multi |
Git Cost Estimate (measured locally despite the rejection — none of this drove the failure)
| Metric | idx196 | idx197 | idx199 |
|---|---|---|---|
| Declared files (stuff.md) | 0 | 0 | 0 |
| Declared history (history.md) | 5 | 5 | 5 |
| Actual patch files | 1 | 1 | 1 |
| Actual patch size | 56.88 KB | 51.4 KB | 205.16 KB |
| Actual commit count | 3 | 2 | 3 |
All three sizes sit far under this workflow's 5120 KB max-patch-size and 200-file max-patch-files caps — the rejection is 100% attributable to the run-level PR quota, not patch size or file count.
🔍 Full Observations
- idx196: Two-dot vs three-dot format-patch diverged by exactly one main-side commit (687-byte phantom), confirming two-dot remains authoritative even under this failure mode. Fast-forward check on the push-delta commit passed (old tip is ancestor of new tip).
push_to_pull_request_branchfailed twice: first missingrepo(target'*'), then missingpull_request_number(no PR existed to reference). - idx197: Parent-count/
--mergescheck confirmed the merge_msg commit is structurally single-parent/non-merge despite its message text — filename leak (0001-Merge-branch-...patch) reconfirmed. Same two-stagepush_to_pull_request_branchfailure (repo, then pull_request_number) as idx196. - idx199: Multi-commit same-file wrapped-append ratio measured at 1.0097x vs a single-commit baseline — reconfirms prior wrapped-text law (~1.0–1.03x, not the ~3x single-long-line blowup) even though the PR itself was rejected. Sub-agent cleaned up its scratch branch/worktree in the real repo after rejection (no residue left).
- idx198 (the one cell that succeeded):
create_pull_requestreturned in 524ms, PR patch size 209,816 bytes / 2714 lines, 204.9 KB (≈4.0% of the 5120 KB cap) — confirms the quota is consumed by the FIRST successful call in a run, not distributed or shared. - No
git push/fetch/pullwas run directly against the real repo by any sub-agent; all real-repo writes were attempted exclusively through thesafeoutputsCLI, per the workflow's safety constraints.
Exploration Coverage
- Configurations tested so far: 200 / 3600
- This batch: cell indices 196–199
- Coverage: 5.56%
Implication for Future Runs
Given the workflow's Phase 2 design fans out 4 parallel sub-agents per run and (per this run's evidence) only the first create_pull_request call in any run can succeed, any future batch containing more than one cell whose BRANCH dimension requires a fresh create_pull_request call will reproduce this exact rejection for all but the first. Prior state notes claiming "196/196 cells passed" going back to 2026-07-xx should be treated with caution: it is unclear whether earlier sub-agent runs (before the general-purpose agent pivot noted in the strategy file) actually verified a real, successful create_pull_request response, or self-reported "pass" based on local git measurement alone without confirming the safe-output side effect. This finding does not itself require a fix in this issue (diagnostic-only workflow) but flags a real constraint on the simulator's own methodology.
Note: This issue documents a systemic finding in the safe-outputs configuration space (run-level PR quota vs. the simulator's parallel fan-out design). It was created by the daily git simulator workflow as a diagnostic report.
Generated by 🧪 Daily Safe Outputs Git Simulator · agent · 258.9 AIC · ⌖ 43.3 AIC · ⊞ 13K · ◷
Activity