What is the limit in number of files or total diff size for a MR or how can I tell that not all files were included in the API response? We fetch MR diffs via GET /projects/:id/merge_requests/:merge_request_iid/changes, but we have an user reporting that not all files in the MR are being listed, and it seems consistent with the limitation they also see in the GitLab cloud UI, where it says “523+ files”.
2 Likes
The response is the the MR with an extra field containing the array of changes (see: Merge requests API | GitLab). Would pagination apply here as well? And why 523?
I’m pretty sure that pagination applies to all the API endpoints.
Why 523? It’s not quite clear to me where that number comes from. This is from one of my current MRs (on the GitLab MR changes page):
16 files
+ 249
- 319
So, 16 files are involved in the changes, 249 lines have been added, 319 lines have been removed in those files.
The pagination for the changes API will paginate the changesets (or patches), not the files involved in the MR. Each “change” is a related set of lines in a file that have been modified by one or more commit (“related” meaning close to each other in the file). It’s these patches that are being paginated.
I’m not sure if that answers your question though?
Just found it. The answer is to look for the “overflow” field in the response, or use access_raw_diffs instead. Source: Merge requests API | GitLab
“Introduced in GitLab 13.6, diffs associated with the set of changes have the same size limitations applied as other diffs returned by the API or viewed via the UI. When these limits impact the results, the overflow field contains a value of true. Diff data without these limits applied can be retrieved by adding the access_raw_diffs parameter, accessing diffs not from the database but from Gitaly directly. This approach is generally slower and more resource-intensive, but isn’t subject to size limits placed on database-backed diffs. Limits inherent to Gitaly still apply.”
Source:
1 Like
Good catch!