+eakuefner

So I dug into this via dev_console. I tried fetching the components for these alerts and kept coming up blank. The bug_components diagnostic exists, and has the expected values:

test_key = utils.TestKey('ChromiumPerf/mac-10_12_laptop_low_end-perf/system_health.common_desktop')
diagnostics = histogram.SparseDiagnostic.query(
   ndb.AND(histogram.SparseDiagnostic.end_revision == sys.maxint,
           histogram.SparseDiagnostic.test == test_key)).fetch()

for d in diagnostics:
  print
  print d.name
  print '%s - %s' % (d.start_revision, d.end_revision)
  print json.dumps(d.data, indent=2)
  print

bugComponents
576341 - sys.maxint
{
  "type": "GenericSet", 
  "guid": "9db84690-da64-41c6-ba14-c8e7c973f0f5", 
  "values": [
    "Speed>Metrics>SystemHealthRegressions"
  ]
}

But these alerts are from [571135 - 571201], some 5000 revisions before the bug component was first seen (as noted above, r576341). Right now, the diagnostic whose range overlaps with the alert's range is used, not the latest. I'd expect a new alert to have the right components, but right now this is WAI. We have a couple options, either just wait since all new alerts should get components as expected, we could also just force older alerts to lookup the components when filing a bug.


As a side note Ethan, it's really nice to see the ranges for these diagnostics, made this really clear what happened.

Ah, I see now. I went through and re-triaged all the old bugs for this benchmark to have the right component (which is how I saw this alert that should have had its own bug, leading to me filing this one). So from my perspective, no action is needed here. Should I WontFix?

Yeah let's WontFix, open again if newer bugs aren't getting the right components.