btw I'm hitting CQ dry run manually now.

CQ+1 vote was removed when you edited commit message and CQ didn't have enough time to notice the vote and triggers job for you.

When you clicked CQ+1 again manually, CQ did have enough time to trigger and I can see jobs running already.

hmm the new title is confusing. The CQ+1 was not removed, at least in UI, after I changed the title.

So, I think CQ+1 was removed in backend because 
  a) that's what gerrit config says to do
  b) you were able to vote CQ+1 later on without removing prior CQ+1.

Now, if you didn't see removal of CQ+1 in UI, that's probably a UI and/or Gerrit backend caching bug UI bug. Please file bug report against Infra>Codereview>Gerrit for agable@ or potentially PG team to look at it. I personally haven't experienced it yet. 

I had to remove +1, see https://chromium-review.googlesource.com/c/chromium/src/+/648249/#message-e9a877db22514f0a23b92e0af6f238794f8d310d

You removed your CQ+1 manually **after** CQ started running:
https://screenshot.googleplex.com/K1gsDAxO2RS
The fact that we are arguing about this strongly suggests current CQ 
integration into Gerrit is far from perfect.

And, yes, CQ latency in reacting to new changes is high in MTV these days: 
http://shortn/_PYRgDw92fb
Unfortunately, I can't reduce these substantially this without architectural changes to CQ daemon code.

Gerrit config is now fixed to ensure CQ vote is copy-pasted on commit message edits https://chromium.googlesource.com/chromium/src/+/refs/meta/config/project.config#7 

As for CQ latency, there will be more improvement in Q3/Q4.