outdated_line_change API endpoint returns an empty response (not showing code changes for outdated comments)

Summary

GitLab automatically adds a note to a thread in a merge request when a later commit to the branch changes the same line. That note contains the option to "Compare changes". Normally, a diff of the new changes is shown inline when clicking this link.

Unfortunately, sometimes the diff never loads and the "loading" animation shows forever.

The issue is not new. I don't remember when I first experienced it, but it must have been at least months, maybe years, with always the latest production version of GitLab running.

I found the same bug described in another GitLab instance: https://foss.heptapod.net/heptapod/heptapod/-/issues/674

Note that this differs from other, albeit similar, reports:

• #363198 (closed) describes that the "Compare changes" link does not always show up. This is not the case here.
• #346758 (closed) describes very similar UX behavior. However, in this case, the HTTP request in the background does not fail with status 500 Internal Server error. Instead, the request succeeds with 200 Ok and the list in the body is empty.

Steps to reproduce

Unfortunately, I was not able to intentionally reproduce the issue. It might be related to either of these traits:

• The comment is not only on a single line, but on a range of code.
• The whole range (or maybe only a part of it) is removed by a later commit.

The general steps are probably:

1. Create a merge request.
2. Add a comment to a changed file.
3. Change the line or range of code that the comment is on and push it in a new commit to the same branch.
4. See that GitLab automatically adds a note saying that there are new changes to this code.
5. Click the "Compare changes" link in this note.

Example Project

What is the current bug behavior?

When clicking the "Compare changes" link, the "loading" animation is shown indefinitely.

The cause seems to be an empty response from the endpoint from which the outdated_line_change is requested:

• The endpoint is GET /{namespace}/{repository}/notes/{id}/outdated_line_change
• The response status is 200 Ok
• The response body is an empty list []

What is the expected correct behavior?

When clicking the "Compare changes" link, the "loading" animation should be shown only until the diff is loaded from the backend. The diff should replace the loading animation.

Relevant logs and/or screenshots

2022-12-20_10-47_gitlab-mr-inline-compare-changes-not-loading

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:         Ubuntu 18.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.7.6p219
Gem Version:    3.1.6
Bundler Version:2.3.15
Rake Version:   13.0.6
Redis Version:  6.2.7
Sidekiq Version:6.5.7
Go Version:     unknown

GitLab information
Version:        15.6.2-ee
Revision:       08b668e8740
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     12.12
URL:            https://gitlab.fairphone.com
HTTP Clone URL: https://gitlab.fairphone.com/some-group/some-project.git
SSH Clone URL:  git@gitlab.fairphone.com:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: google_oauth2

GitLab Shell
Version:        14.13.0
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Results of GitLab application Check

Expand for output related to the GitLab application check

Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 14.13.0 ? ... OK (14.13.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Checking Reply by email ...
IMAP server credentials are correct? ... Checking gitlab@frphn.co
yes
Mailroom enabled? ... skipped
MailRoom running? ... skipped
Checking Reply by email ... Finished
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
2/1 ... yes
3/5 ... yes
3/6 ... yes
84/8 ... yes
84/9 ... yes
2/10 ... yes
8/12 ... yes
8/13 ... yes
8/14 ... yes
6/15 ... yes
8/16 ... yes
8/17 ... yes
8/18 ... yes
11/20 ... yes
18/21 ... yes
18/22 ... yes
18/24 ... yes
16/26 ... yes
29/28 ... yes
11/30 ... yes
3/31 ... yes
155/32 ... yes
8/33 ... yes
155/34 ... yes
8/35 ... yes
6/37 ... yes
37/38 ... yes
33/39 ... yes
33/40 ... yes
33/41 ... yes
33/42 ... yes
33/43 ... yes
37/44 ... yes
18/45 ... yes
5/48 ... yes
155/49 ... yes
29/51 ... yes
29/52 ... yes
29/53 ... yes
29/54 ... yes
72/56 ... yes
6/57 ... yes
8/58 ... yes
6/59 ... yes
6/60 ... yes
6/61 ... yes
37/65 ... yes
11/66 ... yes
156/67 ... yes
8/68 ... yes
8/69 ... yes
6/70 ... yes
72/72 ... yes
72/73 ... yes
30/74 ... yes
29/75 ... yes
29/76 ... yes
29/77 ... yes
29/78 ... yes
29/79 ... yes
29/80 ... yes
29/81 ... yes
29/82 ... yes
37/83 ... yes
29/84 ... yes
72/85 ... yes
327/86 ... yes
156/87 ... yes
6/88 ... yes
6/89 ... yes
6/90 ... yes
8/91 ... yes
322/92 ... yes
8/93 ... yes
156/96 ... yes
5/97 ... yes
8/101 ... yes
29/102 ... yes
37/103 ... yes
6/104 ... yes
6/105 ... yes
321/107 ... yes
156/109 ... yes
156/110 ... yes
6/111 ... yes
6/112 ... yes
5/113 ... yes
321/114 ... yes
30/115 ... yes
5/116 ... yes
18/117 ... yes
153/118 ... yes
156/119 ... yes
321/120 ... yes
72/121 ... yes
18/122 ... yes
156/123 ... yes
156/124 ... yes
318/125 ... yes
322/126 ... yes
85/127 ... yes
155/128 ... yes
328/129 ... yes
156/130 ... yes
30/131 ... yes
18/132 ... yes
6/133 ... yes
Redis version >= 6.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.6)
Git user has default SSH configuration? ... yes
Active users: ... 105
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished

Possible fixes