Another instance here:
https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8932043592699689776

And one more:
https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8932043601580512624

Test failures caused by proto file change introduced in https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1286551, specifically "ea5be34e Pavol Marko         Sync device management proto changes from ..".

Should there be some test preventing incompatible protobuf changes?

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/platform/spacecast/+/81b5d20a6567fe40ebdfd33a52aac59f6852f20e

commit 81b5d20a6567fe40ebdfd33a52aac59f6852f20e
Author: Erdi Chen <erdi@google.com>
Date: Tue Oct 23 00:46:05 2018

+A few ChromeOS Enterprise folks for awareness

In general we try to be backwards compatible with proto changes, but as you see sometimes fields are removed when it is assumed that no one is/should be using them anymore.
I don't know the background of this particular field deprecation - it seems to come from http://cl/214999415 propagating through https://chromium-review.googlesource.com/c/chromium/src/+/1251083 into my change referenced in Comment #3.

I regularly sync the file from the master version in chromium to chromiumos (upreving the protofiles ebuild).
In most cases I manually check for removed fields and codesearch for them, but this time I didn't have the time so I decided to assume that if CQ is happy, it will be fine :-) - Sorry about the breakage!
OTOH I'm not sure I'd have identified this dependency, as I was not aware of the spacecast effort until now and that it depends on the protos.
I'm assuming these tests can't be in the CQ becuase they're in chromiumos-internal. Is there something we could do in our script to ensure that spacecast is not impacted before uploading the sync CL (i.e. which tests would we have to run / what would the command-line inside the cros_sdk be?)

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/platform/spacecast/+/0ec6628f0eba04c61909c77a5b29b6c42ea2460e

commit 0ec6628f0eba04c61909c77a5b29b6c42ea2460e
Author: Erdi Chen <erdi@google.com>
Date: Thu Nov 01 05:47:56 2018

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.