Closed Bug 641461 Opened 13 years ago Closed 7 years ago

Make it easy to add new crashreport fields, or confirm AppNotes in its role as universal custom field (maybe just a documentation issue)

Categories

(Socorro :: General, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bjacob, Unassigned)

Details

Sometimes it's useful for the application to write custom data into crash reports. Ideally, one would want to add a new field, and have it show up in crash reports on crash-stats. The problem is that if I just add a new field, as far as I know, it won't be shown on crash-stats.

The way in which we work around that in the Gfx team is to use the AppNotes field, which is a free-form text field that is shown on crash-stats. This works nicely, but is limited to less than 1 kilobyte. So if another bit of code wrote a lot of stuff already, you can get truncated.

So I would like that:
 * either it gets well-documented how to add new fields and how to control how they appear on crash-stats;
 * or one just says that AppNotes is all we need, and then we probably need to remove the 1 kB constraint.
Examples of stuff we do with AppNotes: bug 627464

Example of how we analyse this data: bug 640286
Component: Socorro → General
Product: Webtools → Socorro
(In reply to Benoit Jacob [:bjacob] from comment #0)
>  * either it gets well-documented how to add new fields and how to control
> how they appear on crash-stats;

I think it's pretty well-documented how to add annotations to a crash report, if not, you#re right that it should be. To get those fields into Socorro, we need explicit bugs filed about adding each of them to either the DB, or the UI to view a crash report, or both. We cannot expose things in either automatically, as some field might be privacy-sensitive, and the DB needs to know about types of fields, etc. which we also probably cannot automate (also, the DBAs seem to like to normalize DB data, which always needs manual work).

>  * or one just says that AppNotes is all we need, and then we probably need
> to remove the 1 kB constraint.

No, I'm pretty mad about our already existing over-use of app notes and would rather have that field removed completely than its use extended.
Our current plan is to allow for a JSON field that can be easily modified. This is dependent on upgrading to 9.2, which should happen relatively soon.

There's at least one blocker to easy schema changes, which is partitioning and the locks associated with production changes. But the JSON field would buy us quite a bit in terms of flexibility and future-proofing.

In any case, I support putting as much as is reasonable into a free-ish form JSON field inside of Postgres, and supporting lots of transform operations on it moving forward.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.