Hmm, yeah, the problem here is that editing the commit message creates a new patchset, and the Commit-Queue label isn't carried forward onto the new patchset. Therefore the CQ sees this as the removal of the CQ label, and cancels its run.

Looks like this was the result of a misconfiguration, so I'm sending this to the git admin to fix.

Git admin: each repo which configures its own Commit-Queue label (e.g. chromium/src, infra/, v8/v8, and some others) needs to have the following diff applied:

[label "Code-Review"]
- copyAllScoresIfNoChange = false
+ copyAllScoresIfNoCodeChange = true

Since the label configuration isn't editable via the UI (issue gerrit:7882), this has to be done via git-fetch'ing the refs/meta/config, editing the project.config file by hand, and pushing the resulting commit.

There are two related issues which should be considered as well to make sure we get exactly the behavior we want:

1) Editing the description causes runs of the CQ to be cancelled, which is probably also undesirable?
2) Editing the description after approvals were granted causes warnings about post-approval-changes

These are both changes from Rietveld and they are *probably* not what we want, but I can see a case being made for them being correct, maybe, so I wanted to explicitly point them out.

Thanks for looking at this.

Yep, we're aware of both of those, and they're conscious decisions.

1) As long as the CQ+1/2 vote is still there, the CQ will immediately start a new run, and re-use jobs from the previous run. So it doesn't add load, and it lets the CQ ensure that it is using the correct CQ_INCLUDE_TRYBOTS parameters if they changed in the commit message.
2) The post-approval-changes warning includes the name of the patchset, which is "Edit commit message" for in-UI edits. We'd like to be able to filter these, but can't without a ton of work on the Gerrit team's side, so we've let this one sit as a low priority desire.

chromium/src config change: https://chromium.googlesource.com/chromium/src/+/5a491b195f48c314705966448c515e77a6bd9f93

Is the config change mentioned in comment#5 supposed to resolve this issue? I'm still seeing the same behavior.

Same here, at least as late as yesterday.

What repo? chromium/src?..

Yes. One example is https://chromium-review.googlesource.com/c/chromium/src/+/806217 where I uploaded it 15:19. Twenty minutes later I noticed that the tryjobs hadn't started and I started them manually from the web page.

Hm, it should have copied Commit-Queue label into the new patchset per https://chromium.googlesource.com/chromium/src/+/refs/meta/config/project.config#14

Not sure why it didn't work...

Filed https://bugs.chromium.org/p/gerrit/issues/detail?id=7929 to follow up on that.