Aaron, can you take a look?

Bugdroid saw the change, but failed to POST to Monorail: https://uberchromegw.corp.google.com/i/internal.infra.cron/builders/bugdroid/builds/28957/steps/bugdroid/logs/stdio (ctrl+f for 653093)

The failure was due to the temporary monorail outage this morning: http://shortn/_4ntnvHnjUg

The outage was caused by jrobbins, so assigning to him so he's aware of this fallout, but marking WontFix because it was a temporary condition and not bugdroid's fault.

Is it a bug for Bugdroid to give up on the change instead of trying again later?

No, bugdroid refuses to go back in time and retry old things, because that causes problems when it is restarted, when the git server goes down, or when there is a merge commit (so it looks like lots of new-but-old commits just showed up).

Bugdroid has a lot of poor design decisions. Unfortunately, it is not even close to the top of the priority stack. It will naturally get better when we switch entirely to Gerrit.

Issue 670756 has been merged into this issue.

My Issue 670756 was duplicated into this one, so commenting here.

https://codereview.chromium.org/2550553002/ for  Issue 670260  definitely landed after the reported outage between from 10:06am to 10:16am Pacific on Wednesday Nov 30. I suspect something else went wrong, but if things are working now, no action needed.

I'd like to point out that the bugdroid run mentioned in #2 above (where the update to  Issue 653093  was dropped):
https://uberchromegw.corp.google.com/i/internal.infra.cron/builders/bugdroid/builds/28957

was green. I recommend changing the recipe so that these sort of POST failures at least turn the step red, so we can observe when things go wrong.