Changing a custom label value causes a server error. Is there a way to unset a previous setting? Gerrit 2.6.1

[Ry Jones]

I have a custom label LV with values:

2: approved for merge

1: pending approval

-1: rejected for merge

If I do:

ssh SGR gerrit review 2472,1  --label LV=1

when LV is unset, no problem, it's now set to 1. then later, do:

ssh SGR gerrit review 2472,1  --label LV=2

fatal: internal server error while approving 2472,1

one or more approvals failed; review output above

it doesn't matter if this is 2 or -1, I get a server error. If I go into the UI, remove my previous LV=1, then re-run the ssh command above, it works. This is Gerrit version 2.6.1. Obviously, using the UI, I can go directly from LV=1 to LV=2.

If there is a work around where I can delete a previous label via ssh, that's fine, too.

[Dave Borowitz]

Do you have a stack trace from the server logs?

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ry Jones]

I do not have access to the server logs. I will try to get a copy.

I did, however, try an experiment on a 2.8 instance. It appears this applies to any label, including defaults:

$ ssh ASA gerrit review 154,1 --label code-review=1

$ ssh ASA gerrit review 154,1 --label code-review=-1

fatal: internal server error while approving 154,1

one or more approvals failed; review output above

$ ssh ASA gerrit review 154,1 --code-review -1

$ ssh ASA gerrit review 154,1 --code-review 1

$ ssh ASA gerrit review 154,1 --code-review -1

so changing the baked-in code-review value directly works as expected, but changing it as a label does not. Thus, the issue isn't confined to my custom label.

[Dave Borowitz]

Based purely on your description it sounds like this is a regression introduced by https://gerrit-review.googlesource.com/52900. If I can find some time I'll try to reproduce, but a stack trace would make it easier :)

[Ry Jones]

I set up a test instance locally to reproduce.

$ ssh CLL gerrit review 1,1 --label code-review=-1

$ ssh CLL gerrit review 1,1 --label code-review=1

fatal: internal server error while approving 1,1

one or more approvals failed; review output above

[2014-01-10 15:18:41,503] ERROR com.google.gerrit.sshd.commands.ReviewCommand : internal error while approving 1,1

com.google.gwtorm.server.OrmException: insert failure on patch_set_approvals

        at com.google.gwtorm.schema.sql.SqlDialect.convertError(SqlDialect.java:152)

        at com.google.gwtorm.schema.sql.DialectH2.convertError(DialectH2.java:45)

        at com.google.gwtorm.jdbc.JdbcAccess.convertError(JdbcAccess.java:448)

        at com.google.gwtorm.jdbc.JdbcAccess.insert(JdbcAccess.java:160)

        at com.google.gerrit.server.change.PostReview.updateLabels(PostReview.java:467)

        at com.google.gerrit.server.change.PostReview.apply(PostReview.java:180)

        at com.google.gerrit.sshd.commands.ReviewCommand.applyReview(ReviewCommand.java:217)

        at com.google.gerrit.sshd.commands.ReviewCommand.approveOne(ReviewCommand.java:276)

        at com.google.gerrit.sshd.commands.ReviewCommand.run(ReviewCommand.java:194)

        at com.google.gerrit.sshd.SshCommand$1.run(SshCommand.java:35)

        at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:442)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

        at java.util.concurrent.FutureTask.run(FutureTask.java:138)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)

        at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:344)

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

        at java.lang.Thread.run(Thread.java:662)

Caused by: org.h2.jdbc.JdbcBatchUpdateException: Unique index or primary key violation: "PRIMARY_KEY_E3 ON PUBLIC.PATCH_SET_APPROVALS(ACCOUNT_ID, CATEGORY_ID, CHANGE_ID, PATCH_SET_ID) VALUES ( /* key:2 */ null, null, null, null, 1000000, 'Code-Review', 1, 1)"; SQL statement:

INSERT INTO patch_set_approvals(change_open,change_sort_key,granted,value,account_id,category_id,change_id,patch_set_id)VALUES(?,?,?,?,?,?,?,?) [23505-173]

        at org.h2.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:1167)

        at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)

        at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)

        at com.google.gwtorm.schema.sql.SqlDialect.executeBatch(SqlDialect.java:390)

        at com.google.gwtorm.jdbc.JdbcAccess.execute(JdbcAccess.java:438)

        at com.google.gwtorm.jdbc.JdbcAccess.insertAsBatch(JdbcAccess.java:202)

        at com.google.gwtorm.jdbc.JdbcAccess.insert(JdbcAccess.java:155)

        ... 16 more

Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: "PRIMARY_KEY_E3 ON PUBLIC.PATCH_SET_APPROVALS(ACCOUNT_ID, CATEGORY_ID, CHANGE_ID, PATCH_SET_ID) VALUES ( /* key:2 */ null, null, null, null, 1000000, 'Code-Review', 1, 1)"; SQL statement:

INSERT INTO patch_set_approvals(change_open,change_sort_key,granted,value,account_id,category_id,change_id,patch_set_id)VALUES(?,?,?,?,?,?,?,?) [23505-173]

        at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)

        at org.h2.message.DbException.get(DbException.java:171)

        at org.h2.message.DbException.get(DbException.java:148)

        at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)

        at org.h2.index.PageBtree.find(PageBtree.java:121)

        at org.h2.index.PageBtreeLeaf.addRow(PageBtreeLeaf.java:148)

        at org.h2.index.PageBtreeLeaf.addRowTry(PageBtreeLeaf.java:101)

        at org.h2.index.PageBtreeIndex.addRow(PageBtreeIndex.java:95)

        at org.h2.index.PageBtreeIndex.add(PageBtreeIndex.java:86)

        at org.h2.table.RegularTable.addRow(RegularTable.java:125)

        at org.h2.command.dml.Insert.insertRows(Insert.java:127)

        at org.h2.command.dml.Insert.update(Insert.java:86)

        at org.h2.command.CommandContainer.update(CommandContainer.java:79)

        at org.h2.command.Command.executeUpdate(Command.java:235)

        at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)

        at org.h2.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:1152)

        ... 22 more

[Ry Jones]

To be completely clear, I set up a test 2.8 instance, but this bug has existed since at least 2.6.1