My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 382: "Unspecified merge failure: REVISION_GONE" error upon trying to submit a patch.
2 people starred this issue and may be notified of changes. Back to list
Status:  CannotReproduce
Owner:  ----
Closed:  Jan 2010


Sign in to add a comment
 
Reported by vinay...@gmail.com, Jan 10, 2010
Affected Version: 2.1.1
Environment: Linux, standard gerrit installation with built-in http daemon
and h2 db.

What steps will reproduce the problem?
1. User A submits the patch. And marks it as verified +1.
2. User B reviews the patch. And marks it as approved +2.
3. User B now tries to submit the patch.

What is the expected output? What do you see instead?
User B expects the patch to get applied and merged. But instead he sees a
error saying "Unspecified merge failure: REVISION_GONE". A mail with the
same message is also sent. Now, this patch cannot be applied no matter what
combination/order of approved/verified/submit operation is tried.

If the patch is pushed again as a fresh patch set, then if the User B marks
it as both verified +1 and approved +2 in a single publish comment
operation and then tries to submit it, it works fine.

Please provide any additional information below.
We can see the following backtrace in the log:
[2010-01-09 22:49:43,165] ERROR com.google.gerrit.sshd.commands.Receive :
Error computing patch of commit 671ebf8f155b9a93d841acf9c0e198351afc1b79
java.io.IOException: Failed to create ref refs/changes/07/7/1 in
/repo/git/infra.git: REJECTED
    at com.google.gerrit.sshd.commands.Receive.createChange(Receive.java:859)
    at
com.google.gerrit.sshd.commands.Receive.createNewChanges(Receive.java:770)
    at com.google.gerrit.sshd.commands.Receive.access$200(Receive.java:102)
    at com.google.gerrit.sshd.commands.Receive$1.onPreReceive(Receive.java:213)
    at
org.eclipse.jgit.transport.ReceivePack.executeCommands(ReceivePack.java:748)
    at org.eclipse.jgit.transport.ReceivePack.service(ReceivePack.java:503)
    at org.eclipse.jgit.transport.ReceivePack.receive(ReceivePack.java:452)
    at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.java:247)
    at
com.google.gerrit.sshd.commands.AbstractGitCommand.service(AbstractGitCommand.java:62)
    at
com.google.gerrit.sshd.commands.AbstractGitCommand.access$100(AbstractGitCommand.java:30)
    at
com.google.gerrit.sshd.commands.AbstractGitCommand$1.run(AbstractGitCommand.java:46)
    at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:405)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
Source)
    at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
Source)
    at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:310)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

Jan 11, 2010
#1 sop@google.com
This sounds like you reset your database.

Did you delete the database and reinitialize it?  Without also doing a
delete of the refs/changes directories in each project?

What happened was the database assigned change number 7 to the patch in
this project, but Gerrit couldn't save it because that change already
existed.  So it aborted the store operation with a REJECTED message.

Later when you pushed the same thing again it was able to get a new number
and assign it.

What database are you using?  The best way to fix your installation is to
force the database's number assignment to go forward by say 1000, so that
the next number it gives out won't overlap with any prior testing you may
have done.
Jan 11, 2010
#2 vinay...@gmail.com
I'm using H2 database. I didn't reset the database. Upon pushing a patch for review to 
gerrit, I see it creates the refs in changes. This step has no problem.

And after the review is completed, and I hit the submit button to merge the patch, it's 
just supposed to merge the patch right? why is it trying to change anything in 
refs/changes? Also, I can consistently reproduce this issue by doing the verify +1 and 
code review +2 in separate operations and then hitting the submit button - which fails.
Jan 11, 2010
#3 sop@google.com
Yes, when you hit the Submit button its supposed to just do the merge.
But submit appears to be failing because the reference wasn't created
correctly during the original push to the project.

When you push a change to refs/for/master internally Gerrit is supposed
to create a refs/changes/yy/nnyy/p reference to point to the commit you
just uploaded.  This ensures that subsequent GCs won't delete the object
from the repository.

But the REVISION_GONE error means that at submit time we can't find the
commit in the repository anymore.  Suggesting something has deleted our
refs/changes/ reference, or that it was never created properly.

From above:

  [2010-01-09 22:49:43,165] ERROR com.google.gerrit.sshd.commands.Receive :
  Error computing patch of commit 671ebf8f155b9a93d841acf9c0e198351afc1b79
  java.io.IOException: Failed to create ref refs/changes/07/7/1 in
  /repo/git/infra.git: REJECTED

IIRC REJECTED means refs/changes/07/7/1 existed but pointed to a different
commit than 671ebf8f155b9a93d841acf9c0e198351afc1b79.  That can't happen
unless the database produced the change_id 7 twice, or someone created the
reference by hand before Gerrit could.
Jan 11, 2010
#4 vinay...@gmail.com
Ok. I cleaned up both the db and the refs/changes and started applying the changes 
and I've not been able to reproduce the issue anymore.  So I agree with your assessment 
above. Thanks for your help. Please close this bug as invalid.

One question regarding upgrade - now I'm running 2.1.1. To upgrade to 2.1.1.1 can I 
simply stop gerrit and do "java -jar gerrit.war init -d site_path" with the new war file?
Is it idempotent?
Jan 12, 2010
#5 sop@google.com
OK, thanks.

Yes, init is idempotent, you can execute it on an existing
site and it will walk through the same questions as before,
only this time the default answers will be your current config.
It will also check that the database schema matches the version
of init you are running, and if not, take actions to bring it
up-to-date.

In this case, upgrading from 2.1.1 to 2.1.1.1 is as simple as
copying the WAR file to overrwrite bin/gerrit.war and restarting.
I try to never do a schema modification in a 2.x.x.y release as
those are strictly for important bug fixes.

But you can also just use init.  It will prompt you to copy the
WAR over the current version.
Status: CannotReproduce
Sign in to add a comment

Powered by Google Project Hosting