Introduce sensible limits for Group dropdown
Summary
Incident issue: gitlab-com/gl-infra/production#2997 (closed) Example failing job: https://ops.gitlab.net/gitlab-org/quality/staging/-/jobs/2299713
Quarantine MR (for staging only): !47223 (merged)
Update:
The test fails due to the delay on the namespace/group selection dropdown on the project creation page. At the time of the incident, the gitlab-qa-sandbox-group
group had almost 6300
subgroups. The user gitlab-qa
used by the test is a member of gitlab-qa-sandbox-group
. The dropdown was probably trying to load all those subgroups.
From the attached video (which was recorded after the number of groups under gitlab-qa-sandbox-group
were down from 6300
to around 4000
), it can be seen that there are two long delays:
- When the user clicks the namespace/group selection dropdown
- When the user types a string to search.
End-to-end test failure stack trace
Failures:
1) Manage Project creation user creates a new project
Failure/Error:
created_project = Resource::Project.fabricate_via_browser_ui! do |project|
project.name = 'awesome-project'
project.description = 'create awesome project test'
end
Net::ReadTimeout:
Net::ReadTimeout with #<TCPSocket:(closed)>
Screenshot / HTML page
Possible fixes
The subgroups under gitlab-qa-sandbox-group should be deleted on a regular basis as intended.
We should unquarantine once the subgroup cleanup issue is resolved