As far as I understand now, change IDs are supposed to be unique at least to a repository/branch (and so they should be unique for reviews for the chromium/src repo master branch).

I'm inclined to trust Change-Ids, since there seems to be a 1:1 mapping from Change Ids to Gerrit CLs (since you can make links like "https://chromium-review.googlesource.com/q/I33588ef09b3bd6d8a22870eaf222a2f17080d4a6").

Failing loudly when things don't look right is generally a good idea, but I'd only invest time in adding extra checks here if there's something that's quick to add.

I found the Gerrit document on change-ID: https://gerrit-review.googlesource.com/Documentation/user-changeid.html

So the change ID is guaranteed to be unique in a branch. In our case, we only care about chromium master, so we should be good.

Besides, I did some experiments trying to modify the change ID from command line and the web interface, both were denied by Gerrit, which is in accordance with the document that once created/generated, change IDs must stay the same.

At this point, I'm pretty satisfied with the robustness of our current approach. Now that the issue regarding commit positions is fixed, it's unlikely to have the mismatch again. For now, I don't think it'd worth the effort to implement some heuristic safeguards. Closing as wontfix and we can come back later if the situation changes.

Thanks for looking into this, resolution sounds good.

Actually, there is still the issue of commit messages matching. If we trust the mapping fully, can we add an assert that the commit messages match exactly before merging PRs?

foolip@: yes! See issue 753487 for the exact problem (and it's not just a "good-to-have", but actually a potential bug at the moment).

Ah, thanks :)