Closed Bug 1237473 Opened 8 years ago Closed 4 years ago

When filing a bug, needinfo the bugzilla account that last touched the line we crash on

Categories

(Socorro :: Webapp, task)

Product:
Socorro
Component:
Webapp
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: khuey, Unassigned)

Details

Socorro knows the stack, and we can get the annotate information from URLs like http://hg.mozilla.org/mozilla-central/json-annotate/444097473d1a/browser/extensions/loop/content/modules/MozLoopService.jsm.  Thus we can automatically needinfo the author of the line of code we're crashing on.  This would be great for getting relevant engineers to look at crashes quickly.
I'd be vary of automating that (doing a needinfo). A good start would perhaps be to list the some information about each line in that table of stack frames in the "Crashing Thread" table. I.e. after the 4th column ("Source") we put in the something about the commit description and who the author was. If the bug description appears to have a bug ID in it that can be a link directly to the bug. 

Is that a good start?
My goal is to get an engineer to actually look at crash bugs that get filed.  needinfoing someone seems like a good way to accomplish that.
Usually with a needinfo there's also a comment, like "Hey Kyle, do you remember if we ever changed back to XUL here?"
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2)
> My goal is to get an engineer to actually look at crash bugs that get filed.
> needinfoing someone seems like a good way to accomplish that.

I no longer work on Socorro, but I like this idea and have some thoughts on how you could start hacking on this now.

This could be a totally separate service that pulls data from crash-stats via the REST API https://crash-stats.mozilla.com/api/, pulls annotate info from hg, and has a token to do the needinfo via the Bugzilla API - you could probably throw this up on Heroku as a worker and be done with it, and not have to deal with getting anything landed in Socorro and shipped in that infra. If it were me, I'd try this first.

Doing this real-time as crashes come in is tricky but doable (could be a processor rule like https://github.com/mozilla/socorro/blob/master/socorro/processor/mozilla_transform_rules.py#L755), or it could also be pulled out of Elasticsearch as a query (ES is updated close to real-time).

This might generate a lot of traffic to bugzilla, I would not be surprised if the bugzilla API throttled it, if you are planning to do this for every unique incoming crash. It might help to batch up the BZ API calls, would need to talk to the bugzilla folks though.

If this should live in the Socorro infra, I think the right place to actually do the work would be a job run by the scheduler ("crontabber"), for example this is the job that periodically scrapes bugzilla to associate signatures with bugs: https://github.com/mozilla/socorro/blob/master/socorro/cron/jobs/bugzilla.py

To hack on this locally, at minimum you'd need Postgres and the Socorro python app installed (e.g. into a virtualenv, like https://socorro.readthedocs.org/en/latest/development/build-from-source.html describes) - then you should be able to run the scheduler, "./socorro/cron/crontabber_app.py --help". The "crontabber" scheduler uses Postgres, and you'd probably want to store data there also about what signatures have already been needinfo'd.

In either case you'd need to have a token for bugzilla and use their API to do the needinfo, I don't think Socorro currently has that sort of access to bugzilla.
(In reply to Peter Bengtsson [:peterbe] from comment #3)
> Usually with a needinfo there's also a comment, like "Hey Kyle, do you
> remember if we ever changed back to XUL here?"

We have automated spam for things like performance regressions, code landing, backouts etc. This doesn't seem that different.
Yeah, and I'd much rather have this start out too noisy and figure out a way to pair it back than not do the ni? at all. *Tons* of potential value in this.
Regardless of where this runs, I think you'd need to do something like:

* query (from ES) all new signatures since last run
* for each un-needinfo'd signature, fetch a single processed crash
** e.g. https://crash-stats.mozilla.com/api/ProcessedCrash/?crash_id=5e3adc26-24b7-4931-8799-3c62a2151222&datatype=processed - this is the same data format stackwalker produces, even if you don't use the REST API
* determine the crashing thread, and this should have the symbolicated info you need to query hg.m.o for
** you can see how the webapp does this in https://github.com/mozilla/socorro/blob/master/webapp-django/crashstats/crashstats/utils.py#L129

{
"function": "PR_WaitCondVar", 
"function_offset": "0xe6", 
"module_offset": "0x222986", 
"frame": 1, 
"module": "libnss3.dylib", 
"file": "hg:hg.mozilla.org/mozilla-central:nsprpub/pr/src/pthreads/ptsynch.c:ad16863d1d45", 
"offset": "0x101a22986", 
"line": 264, 
"trust": "frame_pointer"
}, 


* use result from hg to determine the bug # and dev to needinfo
I don't want to do anything automatically, I just want the "Report this bug in X" link to prefill in a needinfo for the right person.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #8)
> I don't want to do anything automatically, I just want the "Report this bug
> in X" link to prefill in a needinfo for the right person.

Hah, ok that's much easier (assuming you can do this in the bugzilla GET) - this could easily be done in Django when the URL is built, if so. Sorry I misinterpreted "automatically needinfo" from comment 0.
Yeah, I only put the "when filing a bug" in the summary.  My bad.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #10)
> Yeah, I only put the "when filing a bug" in the summary.  My bad.

Or I could start reading the summary of bugs I barge in on. Maybe.

So, I can't figure out a way to set the needinfo flag from enter_bug.cgi ... folks in #bmo don't seem to know of a way.

I assume that's fixable on the bz side, the only thing I'd worry about is that the "file a bug" URL is constructed server-side as part of the HTML, and making a call out to hg.m.o's annotate can be pretty slow and would block page load.

Might be worth considering replacing the link with with JS, looks like hg.m.o sets "Access-Control-Allow-Origin: *" so CORS should work to grab the annotate info, and could construct the "file a bug" URL in JS. The BZ API might be able to set the needinfo flag, but your auth cookie wouldn't make it across a CORS XHR so I'm not sure how auth would work, probably better to just make this settable from enter_bug.cgi per above.

This would be awesome, but everything I'm reading here so far suggests this is a lot of work. Further, because it depends on other systems, I'm concerned it will be fragile over time and require ongoing maintenance work. I don't think the value exceeds the work to build and maintain this.

I'm going to close this as WONTFIX. If someone comes up with a much simpler way of figuring this out, then I'm game for looking at that in a new bug.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.