My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
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
Status:  Released
Owner:  ----
Closed:  Jul 2014


Sign in to add a comment
 
Reported by davidtw...@gmail.com, Jun 6, 2014
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
We also saw this issue.  It lead to not being able to view the merged change via the new screen, but viewing by the old screen was possible.  Full details in this thread: https://groups.google.com/d/msg/repo-discuss/kKrhagOOqSk/svM0hs0xMmgJ
Jun 10, 2014
Project Member #2 David.Os...@gmail.com
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
#3 davidtw...@gmail.com
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
Project Member #4 David.Os...@gmail.com
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
Project Member #5 David.Os...@gmail.com
More SQL queries for corrupted change: [1]

[1] http://paste.openstack.org/show/83754
Jun 18, 2014
Project Member #6 David.Os...@gmail.com
https://gerrit-review.googlesource.com/#/c/57851
Status: ChangeUnderReview
Jul 25, 2014
Project Member #7 David.Os...@gmail.com
(No comment was entered for this change.)
Status: Released
Labels: FixedIn-2.8
Sign in to add a comment

Powered by Google Project Hosting