Skip to content

`detailed_merge_status` MR API response attribute is slow to respond, returns `checking` often

Summary

The Merge Request API introduced a new attribute for getting the merge status: detailed_merge_status. On a larger project, the API did not always return a real state but only checking which I assume being a timeout.

The bug was observed in https://gitlab.com/gitlab-com/www-gitlab-com while re-organising the marketing handbook. I wrote a script to check whether the paths I had modified with git mv are affected in other merge requests.

Steps to reproduce

  1. Query the GitLab API on the Merge Request endpoint on a large project (gitlab-com/www-data-com)
  2. Collect the detailed_merge_status field from the response and print it while iterating the results
  3. Use python-gitlab as library abstract, script in https://gitlab.com/dnsmichi/api-playground/-/blob/main/python/search_mr_contains_path.py

Example Project

wget https://gitlab.com/dnsmichi/api-playground/-/raw/main/python/search_mr_contains_path.py

chmod +x search_mr_contains_path.py

brew install python

pip3 install python-gitlab

export GITLAB_TOKEN=xxx

python3 search_mr_contains_path.py

What is the current bug behavior?

I have seen that the detailed_merge_status API field takes a long time to calculate, sometimes, and only returns checking as the value then.

Context: I wrote a script that queries the GitLab API and checks whether a path is in the diff changes, and its mergeable status. That helped with re-organising the marketing handbook, and helping other MR authors to rebase. Script: https://gitlab.com/dnsmichi/api-playground/-/blob/main/python/search_mr_contains_path.py#L62 Output: gitlab-com/www-gitlab-com#13991 (closed)

What is the expected correct behavior?

The defailed_merge_status API field returns fast. It should return a result set too, and not checking as a value - this is unexpected from an API call, and not documented.

Relevant logs and/or screenshots

Output from the script in https://gitlab.com/dnsmichi/api-playground/-/blob/main/python/search_mr_contains_path.py

- [ ] !115968 - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/115968+ Status: checking, Title: Updating blog coverage details for contractor assistance - adding clarity
- [ ] !115581 - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/115581+ Status: ci_must_pass, Title: Deleting Old Partner-Marketing Tech Alliances Page from Handbook
- [ ] !113867 - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/113867+ Status: checking, Title: Updating the description of how we work together.
- [ ] !111573 - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/111573+ Status: checking, Title: WIP: Add new directory for Corporate Events

Output of checks

This bug happens on GitLab.com /label reproduced 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)

Possible fixes

Cache the merge status field. If collecting the different providers takes too long, consider returning a cached result instead of a checking attribute, or a proper error ("timeout").

There could also be a performance bug - I have seen the UI slowly responding on the widgets too.