Andrew Beveridge

My feedback

  1. 3 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      1 comment  ·  General Feedback  ·  Flag idea as inappropriate…  ·  Admin →

      Hi Andrew,

      After closer review this may not be possible to do the way you requested it.

      Notification is send only for new crash. As you know new crash is based on the hash created from crash report fields. Custom Field data are not used to generate the hash so you may have multiple users generating the same crash. We can send any Custom Field data in the notification but this will be misleading as what you really get is data from the first report that generated this new crash notification.

      Regards,
      Martin

      Andrew Beveridge commented  · 

      That sounds perfect, thankyou!

      Andrew Beveridge shared this idea  · 
    • 12 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        started  ·  4 comments  ·  General Feedback  ·  Flag idea as inappropriate…  ·  Admin →
        Andrew Beveridge commented  · 

        Just had an additional thought that perhaps as an alternative to defining a list of "developer devices", it would be useful to be able to define IP ranges which should be classed as "developer crashes".
        In this case we'd define office IP range, so developer testing would always be tagged and easily identifiable.

        Andrew Beveridge commented  · 

        This would be really helpful! The ability to differentiate between DEBUG and RELEASE builds is great, but even when testing the RELEASE build of our app (e.g. from the Play Store), we're likely to get a higher number of crashes from devices owned by the company for internal use.

        It would be really useful to be able to exclude / filter these out by defining a list of "developer devices" which could be identified by IMEI/Serial or other unique identifier.

      • 2 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          2 comments  ·  General Feedback  ·  Flag idea as inappropriate…  ·  Admin →

          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…

          Andrew Beveridge commented  · 

          Hi Martin,

          Thanks for your help - as mentioned by email you've made an adjustment to the grouping and it's now working better for our specific app.
          I'd appreciate understanding how you've solved that though, if you're happy to share.

          I personally still believe this is something which should ideally be configurable per app, as I don't believe there is a one-size-fits-all solution to the problem.

          In our case we've already found two exceptions to the assumption that class name, file name, line number and app version code are sufficient to group crashes in a useful way; apps where there are many crashes which are re-thrown from elsewhere, and apps which have multiple ABIs or less obvious app version codes for each release.

          I believe it is likely that other apps will find similar inconvenient grouping issues as Tracepot starts getting users with more complex app configurations - apps which catch crashes in JNI libraries, for example.

          I propose adding a section to the app general settings page to configure how crashes are grouped; allowing the user to select / remove elements to include while deciding whether to group or separate crashes.

          In our case for example, I would go into that hypothetical configuration panel and remove "App version code", as there are 4 version codes (4 ABIs, armv7, arm64, x86, x64) for every 1 app release, which will likely lead to us seeing multiple duplicate issues.
          Additionally our app has a web component which can gets updated separately from the native android app, so a crash caused by a bug in the web component can exist across different native app version codes, even on the same architecture.

          Anyway, this is probably fairly low priority since you've solved the main problem for us and nobody else is reporting this as an issue just now, but I'd love to see it configurable in the future.

          Andrew Beveridge shared this idea  · 
        • 2 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            2 comments  ·  General Feedback  ·  Flag idea as inappropriate…  ·  Admin →

            I like this idea with applying tags to crash reports. I also see it as a quite complex feature. We will try to break it into smaller parts so you can enjoy it as soon as possible.

            Andrew Beveridge commented  · 

            I agree this would be really useful; the ability to define rules (for example like filters in gmail) which add tags to reported errors would help a lot.
            These rules could be applied whenever a new crash report comes in to the collector to automatically apply tags based on string/pattern matching.

            If we could also then filter by those tags easily, this would satisfy one of my other requests for a "developer device" whitelist / filter, because we could instead just create a filter which searched for any of our developer device IMEIs in the crash report and gave them a "Dev" tag which we could then filter out.

            Andrew Beveridge supported this idea  · 

          Feedback and Knowledge Base