MR review in multiple tabs can result in partial review visibility

Steps

Visit an MR containing code changes. Open two browser tabs (two windows will be convenient).

In tab A, write a comment in the Conversation view. Click "Start Review".

In tab B, visit Commits, select a commit, select a line of the diff, and make a code comment. Even though you've already started a review, the button "Start a review" is available (rather than "Add to review"). Click "Start a review".

Go back to tab A. Click "Your review" and say "Submit review".

Expected results

Both the conversation comment from tab A, and the code comment from tab B, are published. The MR author sees both.

Actual results

Only the comment from tab A is submitted. The comment from tab B is left pending.

Version

GitLab Enterprise Edition v18.8.2-ee, self hosted instance gitlab.torproject.org

Discussion

Evidently comment submission is being driven by the information available in the browser DOM. This is fundamentally incorrect.

Review submission should involve a process on the server which uses the database to find all the comments to publish.

DOM view update

The MR DOM view in tab A should probably have been updated to be told about the comment in tab B. Other anomalies were visible; for example, "Your review" in tab A said "1" when it should probably have said "2". I don't know if that is a gitlab bug or some kind of problem with the installation/configuration.

But this ticket is not about that. This ticket is a about the fact that MR review submission is apparently driven by DOM content.

Related issues

See also #472646. That is about a separate bug (that the deletion of the pending comment and the creation of the public comment don't occur within the same db transaction, so that it is possible for comments to be duplicated).

Edited Jan 22, 2026 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading