I like your tools, I tested it since few days and it's really cool. By the way, a little improvement could be the possibility to add comment on a crash without closing it. Is it possible to add it in the future ?

So far only two crashes have come in to Tracepot naturally, and they've both been grouped into one "issue" which isn't correct.

The top level exception in the stack trace in these two crashes is different, but I believe Tracepot is trying to be smart and decides which part of the stack trace is relevant for grouping (presumably that is the line which is highlighted in bold in the stack trace, and I'm guessing that is determined as the first trace element which contains the app package name).

The problem with the grouping is that almost all crashes from our app come through the same function (called "caughtError" in the JavaScript interface), as it's a hybrid app with a crosswalk webview.

The issue ID which demonstrates this incorrect grouping is c541872e059b0214.

The ideal solution here in my opinion would be to add a new (numerical) option per app for "Stack trace depth to use for issue grouping", as I suspect this is going to be slightly different for every app.

So far only two crashes have come in to Tracepot naturally, and they've both been grouped into one "issue" which isn't correct.

The top level exception in the stack trace in these two crashes is different, but I believe Tracepot is trying to be smart and decides which part of the stack trace is relevant for grouping (presumably that is the line which is highlighted in bold in the stack trace, and I'm guessing that is determined as the first trace element which contains the app package name).

We group issues by class name, file name (including the line number) and app version code. We do not use the whole first line of a stack trace anymore because it created lots of issues where only the first line was slightly different but the rest of the stack trace was the same. Usually when an ID of some sort is included that changes every time like a window ID.

But I understand your problem. You are catching javascript exceptions and re-throwing them as java exceptions. In the current state all happens in the same file with the same class name and therefore is grouped as 1 issue.

This is not an easy task to solve because I need to take into consideration stack traces from all other apps and there is no clear sign that this is javascript exception so use different grouping. I found some pattern I could probably use but it needs testing.

UPDATE 2016-01-26: Added a comment about how the problem was solved.

Martin

Hi Andrew,

We group issues by class name, file name (including the line number) and app version code. We do not use the whole first line of a stack trace anymore because it created lots of issues where only the first line was slightly different but the rest of the stack trace was the same. Usually when an ID of some sort is included that changes every time like a window ID.

But I understand your problem. You are catching javascript exceptions and re-throwing them as java exceptions. In the current state all happens in the same file with the same class name and therefore is grouped as 1 issue.

This is not an easy task to solve because I need to take into consideration stack traces from all other apps and there is no clear sign that this is javascript exception so use different grouping. I found some pattern…

What would be really good would be if in the UI you could mark a device that had reported a crash as a dev device and all reports from that device would now be develop mode. That way dev and release would be automatically separated without code modification.