Trying to make a comment raises the error: line_code=>["can't be blank", "must be a valid line code"]

[eonpatapon]

Prerequsities

• [x] I'm on the latest version of the plugin
• [x] I've installed the required dependencies
• [x] I've run :h gitlab.nvim.troubleshooting and followed the steps there

Setup Configuration and Environment

require("gitlab").setup({debug = { go_request = true, go_response = true, request = true, response = true, gitlab_request = true, gitlab_response = true, }})

Otherwise, only creds are setup

Bug Description

I'm using a private gitlab enterprise server and this plugin at 38bde8a0e4a982329ab4dc4f214f3f06dfc4e4fd

So I'm able to open a review, then in the review diff in visual mode I select one line (same with multiple lines) and try to add a comment with <leader>c.

The request is like so:

-- REQUEST TO GO SERVER --
POST /mr/comment HTTP/1.1
Host: localhost:38973
Accept: */*
Content-Length: 444
Content-Type: application/x-www-form-urlencoded
Private-Token: REDACTED
User-Agent: curl/8.7.1

{"file_name":"xxxx","base_commit_sha":"ba44dad8a1016eb24b3b28948dbd8be10e51d727","start_commit_sha":"ba44dad8a1016eb24b3b28948dbd8be10e51d727","head_commit_sha":"419920e26de375a8094e269ae55907410a98bc1e","comment":"Test","new_line":309,"old_line":310,"type":"text","line_range":{"end":{"new_line":309,"old_line":310,"type":"old"},"start":{"new_line":309,"old_line":310,"type":"old"}}}

-- REQUEST TO GITLAB --
POST /api/v4/projects/373/merge_requests/747/discussions HTTP/1.1
Host: XXXX
Accept: application/json
Content-Type: application/json
Private-Token: REDACTED
User-Agent: go-gitlab

{"body":"Test","position":{"base_sha":"ba44dad8a1016eb24b3b28948dbd8be10e51d727","head_sha":"419920e26de375a8094e269ae55907410a98bc1e","start_sha":"ba44dad8a1016eb24b3b28948dbd8be10e51d727","new_path":"xxxx","old_path":"xxxx","position_type":"text","new_line":309,"old_line":310,"line_range":{"start":{"line_code":"ae08d147731326a82a8067d18ce9d6c724770eb3_310_309","type":"old"},"end":{"line_code":"ae08d147731326a82a8067d18ce9d6c724770eb3_310_309","type":"old"}}}}

Response:

-- RESPONSE FROM GITLAB --
HTTP/1.1 400 Bad Request
Content-Length: 102
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json
Date: Fri, 04 Oct 2024 12:21:33 GMT
Server: nginx
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Gitlab-Meta: {"correlation_id":"01J9BQMTA4XRN6STGJJYC4K3D1","version":"1"}
X-Request-Id: 01J9BQMTA4XRN6STGJJYC4K3D1
X-Runtime: 0.153909

{"message":"400 Bad request - Note {:line_code=>[\"can't be blank\", \"must be a valid line code\"]}"}

[jakubbortlik]

The comment creation fails with the same error when I try to comment on a renamed file as this is not supported by Gitlab. But from your log it doesn't look like you're commenting on a renamed file. @eonpatapon can you please confirm this and I will open a separate issue for that.

[eonpatapon]

@jakubbortlik no it's not a renamed file. Let me know if you need more debug info.

[tex]

I have the same problem. Not a renamed file. File modified in merge request.

[jakubbortlik]

I have the same problem. Not a renamed file. File modified in merge request.

Hi @tex, would you be able to provide some minimal reproduction steps, I imagine something like two versions of a file that would be part of a review, and the region in either the new or old buffer for which creating a comment fails. This would help a lot in debugging the issue.

[tex]

I have some interesting finding: It didn't work, like reliably did not work, when I tried it. But then I pulled the branch (there was added one commit after I started reviewing it with gitlab.nvim) and now adding comment works. If I add it in prev version of file or I add it in new version of file in the diff view it is always added / shown in the old file. I guess this is how it is supposed to work?

I tried to add comment to a file not modified in merge request, but it seems it is impossible. Is it how gitlab works or gitlab.nvim limitation?

[jakubbortlik]

I have some interesting finding: It didn't work, like reliably did not work, when I tried it. But then I pulled the branch (there was added one commit after I started reviewing it with gitlab.nvim) and now adding comment works.

Thanks for the info. I haven't thought of this possibility and will test it.

If I add it in prev version of file or I add it in new version of file in the diff view it is always added / shown in the old file. I guess this is how it is supposed to work?

This is expected behaviour when commenting on unchanged parts of a file.

I tried to add comment to a file not modified in merge request, but it seems it is impossible. Is it how gitlab works or gitlab.nvim limitation?

This is a limitation of Gitlab - it doesn't allow commenting on moved/renamed files.

[tex]

Unfortunately that is not it. I was able to create comment when there was a commit more on server. Also I wasn't able to create comment into original / not changed part of changed file even when I was up to date. In that situation I was able to place comment into changed code though. Weird.

[tex]

-- REQUEST TO GO SERVER --
POST /mr/comment HTTP/1.1
Host: localhost:43419
Accept: */*
Content-Length: 417
Content-Type: application/x-www-form-urlencoded
Private-Token: REDACTED
User-Agent: curl/7.81.0

{"head_commit_sha":"6e5fc194f82acdcb7a3d9f54afbb3ae8691782ff","old_file_name":"","base_commit_sha":"0c3774b3f1cb8a0d7e9e2b7a635efbb1bdb98179","start_commit_sha":"556d612fb8bf6c227379e369d727e4c487e0ec93","type":"text","comment":"Probably the static cast is needed here. And yes, it is better to put it here as this is its \"source\".\n","new_line":75,"file_name":"xxx\/xxx\/xxx\/xxx.hpp"}

-- REQUEST TO GITLAB --
POST /api/v4/projects/2864/merge_requests/19559/discussions HTTP/1.1
Host: xxx.xxx.xxx.com
Accept: application/json
Content-Type: application/json
Private-Token: REDACTED
User-Agent: go-gitlab

{"body":"Probably the static cast is needed here. And yes, it is better to put it here as this is its \"source\".\n","position":{"base_sha":"0c3774b3f1cb8a0d7e9e2b7a635efbb1bdb98179","head_sha":"6e5fc194f82acdcb7a3d9f54afbb3ae8691782ff","start_sha":"556d612fb8bf6c227379e369d727e4c487e0ec93","new_path":"xxx/xxx/xxx/xxx.hpp","old_path":"xxx/xxx/xxx/xxx.hpp","position_type":"text","new_line":75}}

-- RESPONSE FROM GITLAB --
HTTP/1.1 400 Bad Request
Content-Length: 102
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json
Date: Thu, 30 Jan 2025 14:07:39 GMT
Server: nginx
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Gitlab-Meta: {"correlation_id":"01JJVRKXBHTB7DMKB303NQR64K","version":"1"}
X-Request-Id: 01JJVRKXBHTB7DMKB303NQR64K
X-Runtime: 0.200338

{"message":"400 Bad request - Note {:line_code=>[\"can't be blank\", \"must be a valid line code\"]}"}

-- RESPONSE FROM GO SERVER --
HTTP/0.0 500 Internal Server Error
Content-Length: 260
Content-Type: application/json

{"message":"Could not create discussion","details":"POST https://xxx.xxx.xxx.com/api/v4/projects/2864/merge_requests/19559/discussions: 400 {message: 400 Bad request - Note {:line_code=\u003e[\"can't be blank\", \"must be a valid line code\"]}}"}

[jakubbortlik]

After doing some work on #476 I've found out that this error can be caused by an incorrect identification of the modification_type which then can cause an incorrect setting of the line_range.

To fix this issue, it's necessary to revise the way how the modification type is identified, possibly also how it's then used to set the line range.

EDIT: I've moved my previous note here about the missing line range to a separate issue.

[harrisoncramer]

Closing this issue as old then, we can track that bug in your new issue since you have found the root cause: https://github.com/harrisoncramer/gitlab.nvim/issues/478

[jakubbortlik]

Hi @harrisoncramer, I think #386 should be reopened. I didn't make it very clear that #478 is not really connected to #386 even though I first believed it was. I think #386 could be fixed through a revision of how the diff hunks are parsed. I'm willing to try to fix it as I run into the bug from time to time myself.

[broken-wheel]

Hi, I ran into this issue today. Is there a fix or workaround?

This plugin is really useful, but not being able to comment inline is a real bummer..

[jakubbortlik]

Hi, I ran into this issue today. Is there a fix or workaround?

This plugin is really useful, but not being able to comment inline is a real bummer..

Hi, thanks for reporting this is still an issue. As I mentioned in another somewhat related issue, the way how comment location is handled in gitlab.nvim is not ideal. Could you @broken-wheel please add more detail on the files that cause this issue? Ideally original file content - new file content and the line range on which you are trying to create a comment (in the "old" or "new" buffer). I understand that sharing production code may not be possible, so maybe you'd be able to create some anonymized code that can be used to reproduce this issue.

[broken-wheel]

It's a new file (diffview shows A in the changes window), doesn't matter which line. For example, I tried line 4 from the head of a file (cc -> popup -> add comment w/ draft = false -> perform_action())

from typing import List, Tuple

import numpy as np
import torch  # this line.

# rest of the code follows

Interestingly, comments made from GitLab's web-UI do show up in the reviewer pane at the correct lines for the new code, if that helps.

It's also a very simple feature branch on top of main's HEAD.

[jakubbortlik]

It's a new file (diffview shows A in the changes window), doesn't matter which line. For example, I tried line 4 from the head of a file (cc -> popup -> add comment w/ draft = false -> perform_action())

from typing import List, Tuple

import numpy as np import torch # this line.

rest of the code follows

Interestingly, comments made from GitLab's web-UI do show up in the reviewer pane at the correct lines for the new code, if that helps.

It's also a very simple feature branch on top of main's HEAD.

So I've done some testing and the problem is it's not just any new/added file that would cause this problem. In fact, I'm having a hard time reproducing this issue at all, but I'm quite sure that it still occurs from time to time. I'll try to dig deeper into how the "line codes" are created. I tried it some time ago, and I'm sure there are some issues, but then I prioritized other bugs and features.