GitlabMergeRequset::reviews can sometimes associate a review with the wrong commit. This can happen if multiple commits have the same "created_at" date (the date the commit was pushed to gitlab). In this case, sorting on date will leave the older commit last. When later comparing the date of each commit with the date of a review note, the older commit gets picked.
The consequence of this is that a review can end up stuck with "Re-review required" if the repository requires new reviews for new commits.
Gitlab returns commits in reverse chronological order which I assume is based on author date, but the loop later wants them in chronological order based on committer date. The stream sorted method is stable, so I think we should be set by just reversing the order of the commits before sorting.
The consequence of this is that a review can end up stuck with "Re-review required" if the repository requires new reviews for new commits.
Gitlab returns commits in reverse chronological order which I assume is based on author date, but the loop later wants them in chronological order based on committer date. The stream sorted method is stable, so I think we should be set by just reversing the order of the commits before sorting.