Assume you want to trigger a Jenkins build when a certain magic comment is added to a change. This build then posts a "Build Started" message (which, nowadays, resets labels to a neutral 0 vote) and a "Build Finished" message with the build result after it has finished.

In earlier Gerrit versions (probably < 3.6), the comments associated with the build jobs were posted reliably. For changes that were already submitted, the votes were ignored when the vote on a label was less than before submitting the change. This is according to specs, as the Gerrit documentation states that votes cannot be lowered after submission.

In recent Gerrit versions (we traced it back to at least 3.6.1), this behavior for submitted changes has changed and Gerrit seems to have gotten more strict: when a review is posted with comments and votes, it is ignored entirely if the votes don't meet the requirements (i.e. they try to lower the labels from their state before submission). Gerrit then responds with an HTTP error 409 ("Cannot reduce vote on labels for closed change") and discards both votes and comments entirely.

In the situation mentioned above, the Gerrit user doesn't notice that their magic comment did anything and they aren't even notified of the build result. The gerrit-trigger plugin should therefore try to ensure that any comments it posts to Gerrit are reliably committed and don't disappear because another part of the review (the votes) aren't permitted. A solution might be to retry posting the comment without any votes when Gerrit responds with the aforementioned HTTP error 409.