Motivation
An agent had an exact, already-discovered set of 62 open pull requests and needed their current review feedback. github.sync_pull_request_feedback is the documented exact-PR route, but its public contract and server validation reject more than 50 pull requests. The agent therefore has to partition the set itself.
That is not just cosmetic: submitting two legal exact-feedback batches concurrently produced a retryable persistence result for one item with database is locked. The job executor permits four concurrent jobs, while feedback-facet persistence opens the shared SQLite corpus for each item and does not serialize this workflow class. The item-level retry recovery is useful, but it does not tell the caller how to safely complete the original 62-PR goal.
The repository-wide index is not an equivalent alternative: it intentionally discovers PRs with state=all and can process a much broader population. For an agent that already has the exact open PR set, its extra scope and work are avoidable.
Proposed Solution
Keep the bounded network and local-write contract, but let a caller express a known exact PR set slightly larger than 50 without implementing the adapter's internal batch mechanics. One possible minimal shape is raising the exact feedback input limit to 100 and processing it as one durable job with the existing global request/item budgets. Another acceptable shape is a typed, server-owned continuation or batch plan that serializes sub-batches and returns one parent result.
The contract should make the safe lifecycle mechanical:
- preserve ordered per-PR outcomes and the existing retry semantics;
- bound the total request and item work as today;
- avoid concurrent writer contention introduced solely by caller-side partitioning;
- expose any remaining incomplete coverage or retryable PRs as exact follow-ups; and
- keep repository-wide discovery separate from exact-set refresh.
Alternatives Considered
- Tell agents to manually split every request into at-most-50 PR batches and run them serially. This is possible because the cap is documented, but it leaks scheduling and shared-corpus mechanics into every caller and is easy to get wrong when agents naturally parallelize independent work.
- Use github.index_pull_request_feedback. This is the right tool for a repository-wide author audit, but it performs all-state discovery rather than refreshing the exact open set already in hand.
Impact
MCP exact pull-request feedback synchronization, job lifecycle guidance, and the feedback persistence path. This should not add GitHub mutation, weaken request bounds, or turn corpus reads into network operations.
Observed Evidence
- Public tool contract: 1-50 exact PRs (internal/mcpcontract/pull_request_feedback_contracts.go and internal/mcpserver/scalable.go).
- Runtime: a 62-PR open set required two submissions; concurrent submissions yielded one retryable persistence error: database is locked.
- Source: the job executor admits up to four concurrent jobs, and feedback persistence writes per item through the shared corpus.
Success Criteria
A 62-PR exact feedback request can be completed through a single documented, bounded workflow without caller-managed parallel chunks; its terminal result retains the current per-item recovery and coverage semantics.
Motivation
An agent had an exact, already-discovered set of 62 open pull requests and needed their current review feedback. github.sync_pull_request_feedback is the documented exact-PR route, but its public contract and server validation reject more than 50 pull requests. The agent therefore has to partition the set itself.
That is not just cosmetic: submitting two legal exact-feedback batches concurrently produced a retryable persistence result for one item with database is locked. The job executor permits four concurrent jobs, while feedback-facet persistence opens the shared SQLite corpus for each item and does not serialize this workflow class. The item-level retry recovery is useful, but it does not tell the caller how to safely complete the original 62-PR goal.
The repository-wide index is not an equivalent alternative: it intentionally discovers PRs with state=all and can process a much broader population. For an agent that already has the exact open PR set, its extra scope and work are avoidable.
Proposed Solution
Keep the bounded network and local-write contract, but let a caller express a known exact PR set slightly larger than 50 without implementing the adapter's internal batch mechanics. One possible minimal shape is raising the exact feedback input limit to 100 and processing it as one durable job with the existing global request/item budgets. Another acceptable shape is a typed, server-owned continuation or batch plan that serializes sub-batches and returns one parent result.
The contract should make the safe lifecycle mechanical:
Alternatives Considered
Impact
MCP exact pull-request feedback synchronization, job lifecycle guidance, and the feedback persistence path. This should not add GitHub mutation, weaken request bounds, or turn corpus reads into network operations.
Observed Evidence
Success Criteria
A 62-PR exact feedback request can be completed through a single documented, bounded workflow without caller-managed parallel chunks; its terminal result retains the current per-item recovery and coverage semantics.