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

Prerequsities

I'm on the latest version of the plugin
I've installed the required dependencies
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\"]}"}

@eonpatapon

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.

@jakubbortlik

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

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

@tex

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.

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?

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.

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.

-- 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\"]}}"}

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.

Closing this issue as old then, we can track that bug in your new issue since you have found the root cause: #478

@harrisoncramer

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.

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..

@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..

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.

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.

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.

Had this consistently happen for me in newly added files, and I had a quick peek in the code.

I started from the warning log I gained any time I tried to add a comment to a new file: gitlab.nvim: Comments on unmodified lines will be placed in the old file

This seems to be produced at

gitlab.nvim/lua/gitlab/reviewer/init.lua

Line 196 in 4e0b24f

    
           u.notify("Comments on unmodified lines will be placed in the old file", vim.log.levels.WARN)

which suggests the modification_type is bad_file_unchanged.

get_modification_type calls parse_hunks_and_diff at

gitlab.nvim/lua/gitlab/hunks.lua

Line 236 in 4e0b24f

local hunk_and_diff_data = parse_hunks_and_diff(state.INFO.diff_refs.base_sha)

which in turn calls git diff --minimal --unified=0 --no-color <sha> -- <oldfilepath> <newfilepath> at

gitlab.nvim/lua/gitlab/hunks.lua

Line 100 in 4e0b24f

local cmd = {

The output of this command is then parsed by parse_possible_hunk_headers

gitlab.nvim/lua/gitlab/hunks.lua

Line 19 in 4e0b24f

M.parse_possible_hunk_headers = function(line)

which retrieves hunks based on @@ prefixes.

It turned out that a custom diff viewer I had set up, difft, did not show these hunk headers for newly added files. Removing this custom diff viewer seems to have fixed it. Maybe the problems described in this ticket can be fixed by making parse_possible_hunk_headers always force git to use the default diff tooling?

Weirdly, in the situation I described above, I got the line_code=>["can't be blank", "must be a valid line code"] error when trying to save a comment in Live mode. Whilst in Draft mode, I got no error (other than the 'unmodified lines' warning), and a Draft comment created for gitlab.nvim.

The draft comment did not show up in GitLab's MR view itself, but it did persist after a neovim restart, which I found odd.

@SlayerOfTheBad

@SlayerOfTheBad Thanks for your report and for confirming this issues still persists. One thing is what you say about difft, but I've encountered this also with the default diff tool. The more problem is that the logic of identifying modification types is flawed and needs to be reworked in general. In the mean, could you maybe create a PR with a fix that forces git to use the default diff tool? I don't know when I get the time to looking into this myself and Harrison too seems to be really busy with other things so I'm not sure he will be fixing this himself.

@jakubbortlik

@jakubbortlik I've made a very simple change, #536

I'm sure it won't fix all causes of the issue reported here, but as I haven't been able to replicate them yet, I can't say it is likely to close this ticket.

I do have some speculation that maybe Gitlab uses a slightly different diffing tool than base git (especially for things like merge requests that aren't "latest -> target"), but that's pure speculation, and I don't know enough about Gitlab nor gitlab.nvim internals to say anything about that confidently.

Thanks! I've merged your PR to unblock at least some users.

I'm quite sure I've been able to reproduce this error when placing comments in specific positions around modified/added code and I strongly believe it was because gitlab.nvim incorrectly detected the modification type for the comment. I'll try to look into this.

If you find a reproducible example, I'll gladly have a look too.

@SlayerOfTheBad

If you find a reproducible example, I'll gladly have a look too.

Hi @SlayerOfTheBad. I've finally managed to find a way how to reproduce this error. If you are still interested in having a look at it, here's what you can do to reproduce it and some hints on how to debug this:

clone my testing repo
start a review of this MR
try placing a comment on lines 43-44 in the new version of CONTRIBUTING.md. You can experiment with the line ranges, but I've been able to reproduce the error with selections spanning the newly added code and just after the newly added code.
There is a number of existing comments, one of them I was able to create in the "OLD" buffer in gitlab.nvim, and this one I created in the web interface. You'll notice that the gitlab.nvim comment is missing the "Comment on lines 9 to 10" note, which is present in the comment created in the web interface. In the discussion tree of gitlab.nvim, you can inspect their characteristics of the comment nodes with the <leader>p mapping. Here are the range values for the gitlab.nvim comment:

  range = {
    ["end"] = {
      line_code = "3f454a98e586d1aa0d322e19afd5e67e08f2d3c8_10_44",
      new_line = 0,
      old_line = 0,
      type = "old"
    },
    start = {
      line_code = "3f454a98e586d1aa0d322e19afd5e67e08f2d3c8_9_43",
      new_line = 0,
      old_line = 0,
      type = "old"
    }
  },

while the comment created in the web interface has these values:

  range = {
    ["end"] = {
      line_code = "3f454a98e586d1aa0d322e19afd5e67e08f2d3c8_10_44",
      new_line = 44,
      old_line = 10,
      type = ""
    },
    start = {
      line_code = "3f454a98e586d1aa0d322e19afd5e67e08f2d3c8_9_43",
      new_line = 43,
      old_line = 9,
      type = ""
    }
  },

There are three main differences:

gitlab.com sets the type differently than gitlab.nvim. I assume the way it's done in gitlab.nvim is based on this piece of documentation, which says: "Use new for lines added by this commit, otherwise old.", but apparently, this doesn't create the correct payload. In practice, I've even seen the "expanded" modification type for comments that range over unchanged code that is otherwise collapsed. I should mention though that there is one more complication: gitlab.com seems to be using the notes API for comment creation - this is what I see in the browser developer console when I create a comment: , whereas gitlab.nvim uses the discussions API. That's why comparing the comment payloads of gitlab.com and gitlab.nvim might be misleading, but I still think re-implementing how the modification types are set might be the way to fix this annoying and persistent bug. Ideally, we want to create the same payloads as gitlab.com (including the "expanded" modification type which could be quite tricky. There is vim.fn.foldlevel, but that's unusable because gitlab.com shows 3 lines of context, while Neovim's default is 6 lines and users can override this - we'd have to get this information by comparing the selected range with the diff hunk). Ideally, this should be covered with unit tests, but I ashamedly admit that I've never added a single test for the lua code in gitlab.nvim and I don't know how easy or difficult it would be to test that a particular visual selection in the diffview creates the appropriate comment payload.
gitlab.com sets the new_line and old_line values, while gitlab.nvim leaves them out. This is because the old go-gitlab library didn't support it, but the new client-go library does. This is tracked as a separate issues Ranged comments don't set range correctly #478, but could probably be fixed in one PR.
gitlab.com seems to calculate the line_code differently, see my comment that was created on some added lines: The line is missing in the "old" buffer and so gitlab.nvim sets the "old line" in the start.line_codeto 0: line_code = "8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_0_50",, while gitlab.com sets it to 51, the first line that the comment spans over in the old buffer (line_code = "8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_51_50",). Considering the error reported in this issue mentions line_code, this may actually be crucial to the solution.

One more issue that I've encountered, and I believe it is related, is that gitlab.nvim notifies the user that comments on unmodified lines will be placed on the old file. This is sometimes misleading because the comment will eventually be displayed on the new file because I believe the get_modification_type_from_new_sha function only takes into account the end of the selection range, but it's the beginning of the comment that can be placed on the added code. And more generally, I would prefer comments on unchanged code to be displayed in the "NEW" file, as this would be useful for the suggestions functionality that I'm implementing in this PR.

@jakubbortlik

I opened #580 for a small parser bug in hunks.lua, an omitted hunk count read as 0 instead of 1. That took me into get_modification_type, where I wanted a test and could not write an honest one. Its old_line and new_line are one cursor position expressed twice: the caller derives the second with calculate_matching_line_new, which runs its own git diff, and the function then parses that same diff again.

While drafting that test I realized it has to supply the second number itself, and the only thing that knows the right value is a git diff against real SHAs and real files. So it is either an integration test or a number I made up. Mocking the diff only makes the second one look like the first.

The shape I would aim for is side plus line in, and type, old_line, new_line out, from a single parse. Nothing in that signature has to be derived first. @jakubbortlik's third point above needs the same thing: line_code carries both numbers, and today nothing produces them together.

None of this fixes what is reported here. I tried, but could not reproduce any of the payloads in this thread. If somebody can still trigger the issue, it would help if you could provide the hunk headers as gitlab.nvim sees them, which can be generated with the following command:

git diff --minimal --unified=0 <base_commit_sha> <head_commit_sha> -- <file> | grep '^@@' | cut -d' ' -f1-4

Should be fixed on develop by #582.

Navigation Menu

Repository navigation

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

Prerequsities

Setup Configuration and Environment

Bug Description

rest of the code follows

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

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

Description

Prerequsities

Setup Configuration and Environment

Bug Description

Activity

jakubbortlik commented on Oct 13, 2024

eonpatapon commented on Oct 14, 2024

tex commented on Jan 29, 2025

jakubbortlik commented on Jan 29, 2025

tex commented on Jan 29, 2025

jakubbortlik commented on Jan 29, 2025

tex commented on Jan 30, 2025

tex commented on Jan 30, 2025

jakubbortlik commented on Feb 18, 2025

harrisoncramer commented on Mar 1, 2025

jakubbortlik commented on Mar 1, 2025

broken-wheel commented on Jul 8, 2025

jakubbortlik commented on Jul 8, 2025

broken-wheel commented on Jul 8, 2025

jakubbortlik commented on Jul 11, 2025

rest of the code follows

SlayerOfTheBad commented on Mar 24, 2026

SlayerOfTheBad commented on Mar 24, 2026

jakubbortlik commented on Mar 24, 2026

SlayerOfTheBad commented on Mar 25, 2026

jakubbortlik commented on Mar 25, 2026

SlayerOfTheBad commented on Mar 25, 2026

jakubbortlik commented on Apr 15, 2026

seflue commented on Aug 2, 2026

jakubbortlik commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions