Change stuck in SUBMITTED state but actually merged

[GoogleCodeExporter]

Affected Version:
2.1.2.4-43-g3c55dde

What steps will reproduce the problem?

I encountered this when I pushed a commit and a tag together:

$ git fetch && git checkout origin/master
$ vi CHANGELOG
$ git commit -a
$ git tag -s release-x
$ git push review:project HEAD:refs/for/master

What is the expected output? What do you see instead?

Change status should be consistent with the repository state. git 
fetch/ls-remote/etc all show the ref having been updated to point to the new 
commit, but the web UI shows the commit as being submitted, merge pending.

Original issue reported on code.google.com by jkoles...@google.com on 17 Jun 2010 at 8:19

[GoogleCodeExporter]

Original comment by sop@google.com on 17 Jun 2010 at 8:35

• Changed state: Accepted

[GoogleCodeExporter]

Same thing happened to me.

Original comment by otan...@gmail.com on 20 Aug 2010 at 7:46

[GoogleCodeExporter]

same here. What are we supposed to do with that commit?

Original comment by prenau...@gmail.com on 14 Sep 2010 at 7:18

[GoogleCodeExporter]

I have abandoned mine, just so it won't show on the open listing.

Original comment by otan...@gmail.com on 14 Sep 2010 at 8:15

[GoogleCodeExporter]

go to the database and to this:

reviewdb> update changes set open='N', status='M' where change_id=00000;

You don't need to abandon it. 
Anyway, even thought you did abandon it, you can do it and have your change in 
the correct status.

Luciano

Original comment by lscar...@gmail.com on 14 Sep 2010 at 8:19

[GoogleCodeExporter]

Same thing happens to me with 2.1.5.

gerrit status is "Submitted, Merge pending", but actually merged to git 
repository.

Original comment by Jongwoo....@gmail.com on 26 Oct 2010 at 3:21

[GoogleCodeExporter]

Any solution for this Gerrit status "Submitted, Merge pending" ..

Original comment by sugnes...@gmail.com on 13 Oct 2011 at 7:34

[GoogleCodeExporter]

This is pretty annoying, will this be fixed soon ?

Original comment by Romy.Max...@gmail.com on 5 Nov 2011 at 10:14

[GoogleCodeExporter]

I have solved my problem.
It means that there are something wrong in its Dependencies~ Check carefully

Original comment by szmneo@gmail.com on 15 Nov 2011 at 2:03

[GoogleCodeExporter]

For others googling, you may also do well to check patch_set_approvals for 
'change_open' entries that don't match the open status in changes.

Original comment by ja...@abneptis.com on 3 Apr 2012 at 8:05

[GoogleCodeExporter]

This happens to me whenever I push tags on commits which are not yet merged.

To prevent this, only tag a commit *after* it was merged by Gerrit.

(If it already happened -- the fix from Comment #5 still works)

Original comment by hoef...@gmail.com on 14 Jun 2012 at 10:06

[GoogleCodeExporter]

Worth noting, at least for 2.1.8.*, this results in is:open returning those 
changes stuck in the submitted/merge pending state...

Original comment by ferri...@chromium.org on 3 Jul 2012 at 10:49

[GoogleCodeExporter]

Hi all,

Had the same problem.

The fix is to reset the state of the change to review pending.  That is:

update changes set open='Y', status='n' where change_id=xxxxxxx;

This then makes the Submit Patch button re-appear.  Click on this to submit.

Original comment by eihena...@googlemail.com on 4 Jan 2013 at 5:27

[GoogleCodeExporter]

In Gerrit 2.6 the SQL is slightly different to move the commit to a Merged 
state, the column name in the WHERE clause is different:

UPDATE changes SET open='N', status='M' WHERE change_key = 'I......';

Original comment by blair@orcaware.com on 3 May 2013 at 6:43

[GoogleCodeExporter]

Doing that SQL update on just change_key is dangerous. change_key is not unique 
for each row. At the very least you need project= and branch= as well, but 
sticking with change_id is safest since that's guaranteed unique.

Original comment by nas...@codeaurora.org on 3 May 2013 at 4:14

[GoogleCodeExporter]

Yes, good point, didn't think of that.

In the end, one would have to find the proper change_id using the change_key, 
project and branch name, in either one SQL SELECT and a follow up UPDATE or all 
together in one UPDATE.

Original comment by blair@orcaware.com on 3 May 2013 at 4:17

[GoogleCodeExporter]

https://gerrit-review.googlesource.com/46461

Original comment by sop@google.com on 4 Jun 2013 at 1:46

• Changed state: ChangeUnderReview

[GoogleCodeExporter]

Hi,

I had this error occur in 2.7 rc1. Before finding this issue i tried to upgrade 
to rc2 (hoping it would magically go away). It didin't.

So i updated the SQL db by hand using the method mentioned above. I now get:
"500 Internal server error"

When trying to open some pages. Is there anyway i can fix this. Perhaps a super 
"clean/purge" function? If not any advice would be appreciated!

Chris

Original comment by Chrisnor...@gmail.com on 15 Jul 2013 at 3:13

[GoogleCodeExporter]

For the "500 internal server error" please provide the stack trace of the error 
from the logs/error_log

Original comment by ziv...@gmail.com on 15 Jul 2013 at 11:05

[GoogleCodeExporter]

https://gerrit-review.googlesource.com/49890

Original comment by edwin.ke...@gmail.com on 18 Sep 2013 at 6:20

• Changed state: Submitted
• Added labels: FixedIn-2.7

[GoogleCodeExporter]

Original comment by edwin.ke...@gmail.com on 20 Sep 2013 at 1:03

• Changed state: Released

[GoogleCodeExporter]

after we upgraded to 2.6, issue  of "Change stuck in SUBMITTED state but 
actually merged" was reported now and then. not for the dependency pending , no 
conflict too, not for the cause of " a commit that has a tag". 

some of these cases is of the merged commit is submitted in to server side 
repository just DB record is left to update.  
others of the commit is not even be merged to server side repository.

it is annoyed and can't be retriggered.
any hints?

Original comment by zu.bruce.china@gmail.com on 23 Oct 2013 at 3:30

[GoogleCodeExporter]

We reproduced the same issue with Gerrit 2.8. I think this behaviour is 
resulting from the fact that Gerrit is getting the status of the change from 
DB, and not from the git repository where the real status lies. In our case the 
DB was not updated for any reason, the change was merged but still the DB was 
not up-to-date showing the status of the change still under review. Is there 
any progress on getting the status of the change from git repository from 
repository and not DB ?

Original comment by bassem.rabil on 26 May 2014 at 5:18

[GoogleCodeExporter]

> I think this behaviour is resulting from the fact that Gerrit is getting the 
status
> of the change from DB, and not from the git repository where the real status 
lies.

I'm not sure what you mean by that; the status does not lie in the repo. You 
can check from the state of the destination branch whether the given change has 
been merged in, but you can't, for example, distinguish between NEW and DRAFT 
or NEW and SUBMITTED. That information lies only in the database (for now).

But we don't have transactions that cross repo and db, so sometimes these get 
out of sync.

For most cases where a change has actually been merged, clicking "submit" again 
will detect this and update the state in the database. For others, an admin can 
update the database manually, but we would probably like to know about it so we 
can make the first workaround work more reliably.

Original comment by dborowitz@google.com on 27 May 2014 at 11:41