Large pull requests can yield incomplete provider change sets

Git provider

Other: Azure DevOps, GitHub, and GitLab.

System Info

PR-Agent provider integrations on current main (f7da79cfa061ebb61fb4c109794f94be90ef4b77). The behavior is independent of the model and deployment type.

Bug details

Several provider-specific limits can make a large pull or merge request appear complete while only part of its changed-file set is available:

• Azure DevOps change entries are paginated per iteration. Collecting only the first page omits later entries.
• GitHub's pull-request-files endpoint returns at most 3,000 files. The provider currently materializes and caches the response without comparing it with the PR's changed_files total. In a controlled provider test, a PR reporting 3,001 changed files returned and cached a 3,000-file prefix.
• GitLab can mark both the normal merge-request changes response and the raw-diff retry as overflow=true; raw diffs are still subject to server-side diff limits. The provider currently accepts and can cache the still-overflowed raw response as if it were complete.

For consumers that require the full change set, the provider should either return a validated complete result or raise an explicit provider error. A known partial result must not be cached or reviewed as complete.

Implementation

The provider APIs expose completeness through different limits and response metadata, so each provider has a separate implementation PR. This issue tracks the shared requirement that a known partial change set must never be treated as complete.

• Azure DevOps iteration pagination: PR #3463 opened
• GitHub 3,000-file completeness validation: PR #3467 opened
• GitLab raw-diff overflow validation: PR #3468 opened