xpcshell and browser-chrome-3, in https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=f239e122ce45 and https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=bcefc7d8d885 (stealthy push, managed to only get clobbers and coalesced-away tests on its own push, so https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=72940b27aeaa looks all happy and innocent). As usual when I'm turned loose on a needed-clobber failure, good luck sorting out which of those tests go with what build - my goal is always "retrigger the failures on the original build, to demonstrate that it fails consistently, then after using the clobberer retrigger the build to demonstrate that it passes consistently after a clobber," but the reality of our infra always defeats me. Between retriggers that stay pending for longer than the clobbered build takes to finish, and the way that a retriggered build uploads over the top of the original build, but we download from mirrors that may or may not still serve up the original build instead of the retrigger, all you can tell (once time proves me right that it did get fixed by clobbering) is that failures must have run on an unclobbered build and passes must have run on a clobbered one.

https://hg.mozilla.org/integration/mozilla-inbound/rev/72940b27aeaa made changes to the nsITelemetry interface but didn't rev the UUID. George, didn't I already hit a similar issue on another recent Telemetry push? Anyway, this needs a follow-up |./mach update-uuids nsITelemetry| push.

Comment on attachment 8557913 [details] [diff] [review] Rev UUID on nsITelemetry Review of attachment 8557913 [details] [diff] [review]: ----------------------------------------------------------------- r=me