Last Comment Bug 641461 - Make it easy to add new crashreport fields, or confirm AppNotes in its role as universal custom field (maybe just a documentation issue)
: Make it easy to add new crashreport fields, or confirm AppNotes in its role a...
Status: NEW
:
Product: Socorro
Classification: Server Software
Component: General (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: socorro
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-14 04:17 PDT by Benoit Jacob [:bjacob] (mostly away)
Modified: 2016-09-01 03:33 PDT (History)
5 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Benoit Jacob [:bjacob] (mostly away) 2011-03-14 04:17:55 PDT
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.
Comment 1 Benoit Jacob [:bjacob] (mostly away) 2011-03-14 04:19:06 PDT
Examples of stuff we do with AppNotes: bug 627464

Example of how we analyse this data: bug 640286
Comment 2 Robert Kaiser 2012-11-02 14:35:28 PDT
(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.
Comment 3 Selena Deckelmann :selenamarie :selena 2012-11-02 15:36:12 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.