2038600 - Allow specific Socorro reports to be retained past their default expiration duration.

Status: RESOLVED WONTFIX

(Socorro :: Database, enhancement)

Description

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:beedell.roke_julian_lockhart]]

At id=978792#c6, I was advised to file a new ticket, for:

Currently, Soccorro retains traces for P6M. I imagine that it must continue to do so, by default, for the sake of storage. However, would the option to retain specific traces be feasible, if the user checks a box?

I ask because, for crashes like what bugzilla.redhat.com/show_bug.cgi?id=2386127 describes, the existence of a trace is the difference between it being diagnosable or not.

Comment 1

[Daniel Veditz [:dveditz]]

I'm sympathetic to your desire for this feature -- I've often had my investigations stymied by the 6-month history window! But would this help more than it hurt? Are there alternatives?

For example: if the crash is not reproducible and hasn't happened again in the last X months (currently 6), is it worth fixing? Maybe it's fixed already, or maybe it was a stray cosmic ray (or statistically more likely, bad memory chips). Would the data in the crash report actually help fix the bug if no one did anything with it for 6 months?

If the crash information is actually useful, could we make it easier or possible to save it as an attachment on a bug report? There are certainly times where I, for one, would love to compare current crashes on a specific signature with one in an older bug report to make sure they really are talking about the same bug.

How much of what Socorro has is necessary for such a diagnosis? If the public data is sufficient, could a reporter save that data in a convenient-enough form and attach it to a bug? If nothing else, "Save As..." the web page might be better than nothing.

I don't work on Socorro so these are mostly random drive-by thoughts, although this request did spark some professional interest in how the feature you're requesting could be abused and what sorts of limitations we'd have to build around it.

Comment 2

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:beedell.roke_julian_lockhart]]

If the crash information is actually useful, could we make it easier or possible to save it as an attachment on a bug report?

I would certainly prefer that, in retrospect. However, I shall be surprised if it is easier to implement.

Comment 3

[Lonnen :lonnen]

I'm no longer involved in the development of Socorro, but I bet that copying the public data into a bugzilla attachment is the easiest path. One you might be able to implement without any changes to Socorro itself.

A crash ID can be taken from a page matching this URL scheme:
https://crash-stats.mozilla.org/report/index/{{crash-id}}

And appended to this API:
https://crash-stats.mozilla.org/api/ProcessedCrash/?crash_id={{crash-id}}

like so:
https://crash-stats.mozilla.org/api/ProcessedCrash/?crash_id=6ca08929-8820-4704-bdc7-bf4e70260511

A request to that url will return some JSON with the same information that is used to populate the UI page.

A Firefox extension could (via Page Action or other mechanisms) provide some UI when on a crash report page that, when clicked, parses out the crash-id and calls that API in the browser. In Firefox a JSON response is displayed with buttons that allow the user to copy or save the response, which can then be attached to a bug.

There's a lot of ergonomic improvement that could be done from there, but as a first pass it would enable quickly materializing a crash into a bug report using only public information into just a few clicks.

Comment 4

[Bianca Danforth [:bdanforth]]

Thank you for the suggestion. We don't have the bandwidth to work on this unfortunately.