Bugzilla

I want to distinguish java exception crashes from native code crashes in the ping metrics. I've come up with 3 options, but I'm wondering which is preferred (if there is precedence for this sort of thing):
1. Use a different `processType` value. The java exception _does_ technically come from a different process, but ultimately the user experiences something equivalent to a `main` crash. Since we generally use `main` crashes to determine the severity of crashes (users are always aware of `main` crashes after all), I'm hesitant to add another case that is the same severity.
2. Use a new reason code for the crash ping. This would work, though I think the ping reason codes are intended to be used for the reason that the ping is being sent, so this might be considered a bit mismatched (but ultimately this could be okay).
3. Make the distinction implicit based on the presence of other metrics in the ping. For example, we're likely going to add an `exception` metric which has the java exception details, which would be mutually exclusive with the `stack_traces` metric (which is designed specifically for native code stack traces so shouldn't be used to send e.g. exception stack traces).

chutten: is my assessment of the reason code correct? Opinions?
royang: any opinions or preferences on which would be best for ingestion and processing of ping data? I think they all should be approximately the same effort when it comes to filtering, with (3) being a bit less precise since it doesn't inherently enforce the mutual exclusivity. Though if we put some time into supporting cross-language stack traces the shape of these metrics will have to change anyway.

I want to distinguish java exception crashes from native code crashes in the ping metrics. I've come up with 3 options, but I'm wondering which is preferred (if there is precedence for this sort of thing):
1. Use a different `processType` value. The java exception _does_ technically come from a different process, but ultimately the user experiences something equivalent to a `main` crash. Since we generally use `main` crashes to determine the severity of crashes (users are always aware of `main` crashes after all), I'm hesitant to add another case that is the same severity.
2. Use a new reason code for the crash ping. This would work, though I think the ping reason codes are intended to be used for the reason that the ping is being sent, so this might be considered a bit mismatched (but ultimately this could be okay).
3. Make the distinction implicit based on the presence of other metrics in the ping. For example, we're likely going to add an `exception` metric which has the java exception details, which would be mutually exclusive with the `stack_traces` metric (which is designed specifically for native code stack traces so shouldn't be used to send e.g. exception stack traces).

chutten: is my assessment of the reason code correct? Opinions?
royang: any opinions or preferences on which would be best for ingestion and processing of ping data? I think they all should be approximately the same effort when it comes to filtering, with (3) being a bit less precise since it doesn't inherently enforce the mutual exclusivity. Though if we put some time into supporting cross-language stack traces the shape of these metrics will have to change anyway.

*Note*: There are also exceptions which _aren't_ fatal. I'm not sure how we should handle these (are they even considered crashes?). But at the moment lib-crash doesn't event call this method for the registered `CrashTelemetryService`s so it's not an immediate concern.

I want to distinguish java exception crashes from native code crashes in the ping metrics. I've come up with 3 options, but I'm wondering which is preferred (if there is precedence for this sort of thing):
1. Use a different `processType` value. The java exception _does_ technically come from a different process, but ultimately the user experiences something equivalent to a `main` crash. Since we generally use `main` crashes to determine the severity of crashes (users are always aware of `main` crashes after all), I'm hesitant to add another case that is the same severity.
2. Use a new reason code for the crash ping. This would work, though I think the ping reason codes are intended to be used for the reason that the ping is being sent, so this might be considered a bit mismatched (but ultimately this could be okay).
3. Make the distinction implicit based on the presence of other metrics in the ping. For example, we're likely going to add an `exception` metric which has the java exception details, which would be mutually exclusive with the `stack_traces` metric (which is designed specifically for native code stack traces so shouldn't be used to send e.g. exception stack traces).

chutten: is my assessment of the reason code correct? Opinions?
royang: any opinions or preferences on which would be best for ingestion and processing of ping data? I think they all should be approximately the same effort when it comes to filtering, with (3) being a bit less precise since it doesn't inherently enforce the mutual exclusivity. Though if we put some time into supporting cross-language stack traces the shape of these metrics will have to change anyway.

**Note**: There are also exceptions which _aren't_ fatal. I'm not sure how we should handle these (are they even considered crashes?). But at the moment lib-crash doesn't event call this method for the registered `CrashTelemetryService`s so it's not an immediate concern.

I want to distinguish java exception crashes from native code crashes in the ping metrics. I've come up with 3 options, but I'm wondering which is preferred (if there is precedence for this sort of thing):
1. Use a different `processType` value. The java exception _does_ technically come from a different process, but ultimately the user experiences something equivalent to a `main` crash. Since we generally use `main` crashes to determine the severity of crashes (users are always aware of `main` crashes after all), I'm hesitant to add another case that is the same severity.
2. Use a new reason code for the crash ping. This would work, though I think the ping reason codes are intended to be used for the reason that the ping is being sent, so this might be considered a bit mismatched (but ultimately this could be okay).
3. Make the distinction implicit based on the presence of other metrics in the ping. For example, we're likely going to add an `exception` metric which has the java exception details, which would be mutually exclusive with the `stack_traces` metric (which is designed specifically for native code stack traces so shouldn't be used to send e.g. exception stack traces).

chutten: is my assessment of the reason code correct? Opinions?
royang: any opinions or preferences on which would be best for ingestion and processing of ping data? I think they all should be approximately the same effort when it comes to filtering, with (3) being a bit less precise since it doesn't inherently enforce the mutual exclusivity. Though if we put some time into supporting cross-language stack traces the shape of these metrics will have to change anyway.

**Note**: There are also exceptions which _aren't_ fatal. I'm not sure how we should handle these (are they even considered crashes?). But at the moment lib-crash doesn't call this method for the registered `CrashTelemetryService`s so it's not an immediate concern.