Download buttons show up instead of the diff when reloading the page while the "Show one file at a time on merge request's Changes tab" preference is active
Enable the "Show one file at a time on merge request's Changes tab" preference
Go to a MR
Select the "Changes" tab
Refresh the page
Example Project
What is the current bug behavior?
Two download buttons show up:
What is the expected correct behavior?
The diff should show up.
️ If I collapse and expand the file, the diff shows up.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)
(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)
I encountered this for files in an MR after the 40th file. Toggling inline/side-by-side, show whitespace changes, or tree/list views didn't seem to affect it.
I want to second this bug too. It just happens to an important MR with many changes in our team. The download button appears on a file with only 347 changes and it makes me unable to review/comment on the change! I have to review it locally then comment on gitlab.com as a workaround
Customer is also experiencing this behavior. I was able to replicate it by enabling Show one file at a time but the diff doesn't appear to be hitting our limits
@m.zollneritsch Are you able to recreate this on GitLab.com? Can you do that in either a public project or invite @thomasrandolph to the project to take a look?
I tried here m.zollneritsch/large-review!3 but sadly I could not reproduce the same behaviour. I thought it is the number of changed blocks but that does not seem to be the case.
But I looked into the diffs_batch.json of WorkOrderDetails.tsx from above and this was the response:
@phikai there is a work-around (disabling file by file mode) but is not very obvious and causes disruption to the single-file Code Review flow, which since it's displayed in the cog menu, might be the main way of doing code review for many users/customers (as can be seen by comments in this issue).
I'm keeping severity (only due to being behind the file by file mode) but raising priority to priority2 and aiming at %14.3. Weight also set to w2 (assuming some investigations during %14.2). If we end up not knowing what this is by the time of scheduling, we ramp it up to a w3.
GitLab has some limits for rendering such diffs. That's understandable. However, we found some cases where we are not happy with how GitLab renders a Merge Request Diff. We got some negative internal feedback from developers that they can't review certain file changes.
The workaround (If I collapse and expand the file, the diff shows up) works. As to severity it makes MR reviews impossible in some conditions, if you don't know the workaround. I will know that now but for sure not all developers in my organization will know about it (I will share the issue and workaround) and this will add general frustration with the MR review process. For me personally it's high priority