Discussions for code-review split up in a very weird way, with new comments ending up on an old commit and old comments end up on new commits (that part is really old)
Expected behavior
This is what it looked like 4 days ago (sorry for the cut-n-paste image, I didn't have a cached version of the site in my browser)
As seen all comments in the correct order in the same discussion.
Actual behavior
This is how it ends up now, with the newest comment being on the old commit and vice-versa
(Possible 8.13 regression, #23101 (closed) being the meta-issue)
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@DouweM when you have time, I'd like to talk about this. The discussion that's been separated has a position pointing to an old HEAD commit SHA (it points to the one in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6945#note_17108886), so it looks like it maybe didn't get updated one time during the note position update? That's the only thing I could think of that could cause this to happen, as the two threads have separate discussion IDs and positions now 😕
That there were two instances makes me doubt this slightly, but I can't see anything else to explain it. If diff notes weren't correctly being calculated as active, then we'd see this much more often. So I realise it's a bit of a cop-out, but my current belief is that this issue happens when we don't update all diff notes. I don't know if there's a way we can have a more robust way of handling this, but if this has only happened twice since the new diff notes were introduced, maybe we don't need it.
Sean McGivernAdded ~12980 ~695347 and removed ~17876 labels
@smcgivern One thing worth noting is that the screenshots in this issue description show the new comment being added to an outdated diff, but in my case the original comment was on the outdated diff and the new comments were added to the current diff.
Has it been ruled out that simply rebasing is causing the issue?
Open an MR
Leave a diff comment
Rebase the branch on a newer version of master and force push it
@deckar01 that's a good suggestion, but yes 🙂 You can see that in your example, the head SHA is set to dc7b1c08, which was after you rebased the first time. I think it's possible that rebasing is related, because that tends to have more commits to process, but that's only a guess.
@smcgivern may be relevant, I'm fairly certain that I rebased and pushed around that time as well. (Don't really remember, but I usually rebase before pushing)