| Issue 2702: | Duplicate patch set sometimes created during submit using cherry-pick submit type | |
| 3 people starred this issue and may be notified of changes. | Back to list |
We've got an odd situation where occasionally when a change is submitted, two patchsets with identical SHA1 hashes are created. It becomes a problem when you try to later post a comment via the gerrit command line using the SHA1 hash, and you get a message back saying that there are multiple patchsets matching that revision.
We are using Gerrit 2.8, cherry-pick submit type. This has happened only 25 times out of the last ~5000 merged changes. Usually the two patchsets are about 7 seconds apart, though one pair was 32 seconds apart.
Here are two queries that I think should both return zero, but instead they return 26 and 25 respectively:
SELECT COUNT(*) FROM
(SELECT changes.change_id AS changeid,
MAX(patch_sets.patch_set_id) AS max_patch_set,
changes.current_patch_set_id AS current_patch_set
FROM changes
JOIN patch_sets ON changes.change_id=patch_sets.change_id
WHERE changes.status='M'
GROUP BY changes.change_id
) subq
WHERE max_patch_set != current_patch_set;
SELECT COUNT(*) FROM
(SELECT COUNT(*) AS thecount,
revision,
change_id
FROM patch_sets
GROUP BY revision, change_id
) subq
WHERE subq.thecount>1;
Jun 9, 2014
#1
pedah...@gmail.com
Jun 10, 2014
We facing the same problem. For example this change was corrupted about one week ago: [1].
The same picture in the database: [2].
The developer told me that he didn't do anything special with this change:
[...]
everything as usual, i went through the files, then clicked 'review',
set 'verified' and 'code-review' and clicked 'publish and submit'
[...]
We can see from the above that old change screen is used.
To find all corrupted changes, i change the query to be:
SELECT changeid FROM
(SELECT changes.change_id AS changeid,
MAX(patch_sets.patch_set_id) AS max_patch_set,
changes.current_patch_set_id AS current_patch_set
FROM changes
JOIN patch_sets ON changes.change_id=patch_sets.change_id
WHERE changes.status='M'
GROUP BY changes.change_id
) subq
WHERE max_patch_set != current_patch_set
ORDER by changeid;
[1] https://gerrit.libreoffice.org/9665
[2] http://paste.openstack.org/show/83478/
Status:
Accepted
Labels: -Priority-Minor Priority-Major
Jun 11, 2014
Note than in 2.9-rc2, the presence of duplicate patch sets on a change means that I now get a 404 in the UI for that change.
Jun 11, 2014
Sure, but only on the new change screen. It does work as expected on old change screen. For more details on why this happens see this discussion on dev ML [1]. [1] https://groups.google.com/forum/#!topic/repo-discuss/kKrhagOOqSk
Jun 11, 2014
More SQL queries for corrupted change: [1] [1] http://paste.openstack.org/show/83754
Jul 25, 2014
(No comment was entered for this change.)
Status:
Released
Labels: FixedIn-2.8 |
|
| ► Sign in to add a comment |