This has nothing to do with git cl try, but with Gerrit & CQ. AFAIS from CQ logs, the first time Gerrit query for CLs with CQ votes gave back your CL (1389358, ps#3) was 9:31 AM PST, which is after you manually voted CQ+1. 

This looks like Gerrit's bug. Looking at messages displayed for your CL I can see:
09:12 AM: new PS #3 uploaded
09:12 AM: CQ+1 vote recorded
09:15 AM: tricium comment
09:31 AM: CQ+1 vote recorded, again, from sky@

09:31 message suggests Gerrit just forgot about earlier CQ+1 voted on in 09:12.


I'm pretty sure it's not the first time this happens, but since this is so recent, maybe Gerrit folks will be willing to debug and fix it?
to +ajp@ to decide what to do with it.

I'm pretty sure this is been happening pretty regularly the past couple of days and not a one off.

Talking with Andrii more and looking in depth at https://crrev.com/c/1389358 ... I suspect the issue is that at 9:12am patch set #3 was uploaded and yet the CQ+1 label was applied to patch set #2, also at 9:12am. Gerrit is configured to drop the CQ label on patch set upload if it isn't a trivial rebase or non-code change. Still suspicious and likely a Gerrit issue / race condition. I suspect these commands are hitting different servers and this is the result.

sky@ - To help in any bug report for Gerrit, can you confirm the order and details of your commands. I'm assuming you:

(1) Ran 'git cl upload' to upload a new patch set.
(2) _after_ upload ran 'git cl try'?

If you did it the other way around this is confusing, but probably working as intended (or at least configured).

Thanks!

I generally do:

git cl upload -m foo && git cl try

I have been doing this for a *long* time and started having problems with this only recently. I plan to switch to git cl upload -m foo --cq-dry-run (Andrii just pointed out cq-dry-run to me).

I have filed http://b/122685545 for this. Unfortunately there's no good way to dupe (or move) this bug to Buganizer. If Gerrit team accepts the Buganizer bug I will close this issue and let everyone follow along there.

And yes, if we're right about the underlying issue --cq-dry-run should fix it by doing all of this in a single request. Let us know if that doesn't work.

Closing this issue. http://b/122685545 is the better home for tracking the long term fix for dealing with the replication issues and we have a short term alternative with --cq-dry-run.