As mentioned in the replies of the issue[1]:
Since change 71424[2], a call to setUpdateRef(false) was added on the
ChangeInserter. BatchUpdate.addRefUpdate is what causes the
batchRefUpdate member to be initialised, but when
ChangeInserter.setUpdateRef is false, the ChangeInserter.updateRepo
method does not call addRefUpdate. So when addRefUpdate is not called,
batchRefUpdate remains null. And in BatchUpdate.execute, the call to
gitRefUpdated.fire(project, batchRefUpdate) is only called when
batchRefUpdate is not null. Result is that ref-updated events are not
fired when a new change is uploaded.
To clarify, updateRef needs to be set to true to keep the same flow as
when the command is created on the spot. Or else we would need to get
access to the RepoContext created in executeRefUpdates somehow, which
would generate a special case flow.
Simply changing to setUpdateRef(true) would result in a LOCK_FAILURE
since it would create a duplicate to an already in progress command and
they would be trying to access the same ref simultaneously.
The idea of the fix is to set the command which was already completed
beforehand instead of creating a duplicate just so the event gets fired
properly when checking its status.
[1] https://code.google.com/p/gerrit/issues/detail?id=3767
[2] https://gerrit-review.googlesource.com/#/c/71424/2
Bug: Issue 3767
Change-Id: I5abd0da87058a4f5a70e44be284c4091aa04c8ec
72cf2fc65f