I've noticed that Commits count are not being updated on load. I think it may have been the case before, but became more obvious after !100390 (merged) as we now generate merge request diffs asynchronously so we may not have them available during the initial page load.
@pedroms It happens when creating merge_request_diff takes longer as they are asynchronously generated now. It happens mostly when you creating an MR from a large forked project such as gitlab-org/gitlab.
You can see how it behaves locally by stopping your sidekiq workers before you create an MR and restarting them after the MR is created.
All SUS-impacting issues need to have a proper severity label set.
Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.
If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.
@vkarnes upon a closer look this seems more like a bugperformance (Performance defects or response time degradation) instead of bugux (Unexpected and unintended behavior that is detrimental to the user experience.) We didn't intentionally design this behavior and then found it had gaps, or that users found it unexpected. Per the description, this buggy behavior is about a change in response times. I'm tentatively relabeling it to bugperformance.
@jay_mccure can you take a look and see if my thinking makes sense?
I would classify as a general typebugseverity3SUSImpacting as it is broken feature with a workaround (work around being to refresh the page). It only affects large repositories.
When raising an MR I think a lot of users would look at this commit count to re-assure themselves that they have pushed/selected the correct branch, so I think it does have UX implications. It's certainly performance related but the fact that the count doesn't update at all until a refresh makes it seem like a regular bug.
@dskim_gitlab in my case I didn't see the pipelines or changes count load either, but I noticed "Building your merge request" message either that you have in your screen capture. Am I hitting the same issue?
@jay_mccure It doesn't load them automatically. It loads them as you click tabs so you would've been able to load Changes and Pipelines eventually without full refresh, but not Commits which is what this issue is about.
It was introduced to workaround the performance issue as users were not able to create MR due to 500 errors. I'd say it's an improvement, but we need to fix rough edges like this one.
All SUS-impacting issues need to have a proper severity label set.
Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.
If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.