How to Resolve GitLab MR Inline Discussion 'line_code' Error in ChatGPT Code Review Workflow

The error message indicates that GitLab’s API is rejecting the discussion creation payload because a required parameter for inline comments—namely the “line_code”—is either missing or empty. In your successful Postman request, all the fields are correctly provided so that GitLab is able to compute or accept the inline discussion. In your n8n workflow the same payload is generating a 400 error with a note saying:

  "can't be blank" (and "must be a valid line code")

Here are a few suggestions for troubleshooting and resolving the issue:

1. Verify Inline Discussion Values

When creating an inline discussion on a merge request, GitLab requires valid positional information. Your payload includes several position fields such as:

 • position[position_type]
 • position[old_path]
 • position[new_path]
 • position[start_sha]
 • position[head_sha]
 • position[base_sha]
 • position[new_line] (set to -1)
 • position[old_line] (set to -1)

When these values indicate a “no specific line” comment (using -1), GitLab still might expect a corresponding “line_code” (which is normally computed based on the diff). In some cases you may need to either:

 - Provide a valid line code if you’re actually targeting a specific line; or
 - Omit all inline positional parameters altogether if you wish to post a general (non-inline) discussion.

Double-check the GitLab API documentation for merge request discussions to see how to structure your payload when you do not intend to comment inline.

2. Ensure the Request Body Matches What GitLab Expects

Since copying the body from the error detail into Postman works correctly, compare your n8n payload formatting with that of Postman. Note that:

 - The fields must be sent as form fields with the exact names (including the bracket notation) and valid values.
 - If you’re using an expression to format JSON or form data in n8n, ensure that the entire JSON is wrapped in double curly brackets so that it is correctly parsed. For example:

JSCopied
{{ {
  "body": "**Decision: Reject** ...",
  "position[position_type]": "text",
  "position[old_path]": "test.txt",
  "position[new_path]": "test.txt",
  "position[start_sha]": "febcb67229d0b14643eb3c6b1d04dd2d8c3a7caf",
  "position[head_sha]": "7ab0f1127e9b162422686febaffc2386c5584b1a",
  "position[base_sha]": "febcb67229d0b14643eb3c6b1d04dd2d8c3a7caf",
  "position[new_line]": -1,
  "position[old_line]": -1
} }}

This practice (while not always the source of this specific error) ensures that the JSON is sent in the correct format.

3. Adjust Fields Based on Your Intent

• If you intend to create an inline comment:
   Make sure you either compute or supply a valid "line_code" (which may require retrieving it from the merge request diff data).

• If you do not intend an inline comment:
   Consider removing the positional fields entirely (or use the parameters for non-inline discussions according to GitLab’s docs). This way, GitLab won’t try to compute a line code from positions that are effectively “no comment” markers.

Conclusion

The error occurs because GitLab expects a valid "line_code" when inline positional parameters are provided. You should either provide a computed valid "line_code" or remove the inline position fields if you want to post a general discussion. This adjustment in your payload should resolve the API error in your n8n workflow.

If further troubleshooting is needed, you might compare the full HTTP request generated by n8n with the one sent from Postman to identify any discrepancies in headers or payload formatting.