Mark Finkle (:mfinkle) (use needinfo?) Reporter
	Description • 8 years ago

A crash ping exists for desktop:
https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/telemetry/crash-ping.html

I'd like to send one from Android (and iOS). I want to keep the ping small, so I want to skip sending the environment payload. It looks like the crash ping supports not having the environment, so we could just set hasCrashEnvironment = false.

We should be able to send the ping from our Java CrashReporter code.

Once we start sending the pings, I want to import the data into Presto/Redash much like we do for events and add-ons. I suppose the data could also be imported into crash_aggregates, but I am not familiar with the format and how easily that datasource can work with our existing event and add-ons data sources.

	:Margaret Leibovic
	Comment 1 • 8 years ago

We should make an Aha card for this.

	:Margaret Leibovic
	Comment 2 • 8 years ago

Mike, Georg, can you advise on the best way to go about doing this? This seems well scoped enough that someone without a lot of experience with the telemetry code could pick it up.

We'd probably want to send the ping somewhere from inside CrashReporter.java or CrashHandler.java. How hard is it to get our Java uploader to submit a new ping type?

It looks like the format requires a session ID, so maybe this is blocked on getting session tracking landed.

	Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]
	Comment 3 • 8 years ago

Assuming we don't drastically change the new uploader implementation, the TelemetryDispatcher javadoc should explain how to do this:
  https://dxr.mozilla.org/mozilla-central/rev/369a5ee3a2880a4a98df3a00bf3db8d8f36b181b/mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryDispatcher.java#37

I think it should be mostly straight-forward, essentially filling in the blanks, exception to the caveats below.

One caveat is that I didn't consider how the dispatcher would run from multiple activities. The Dispatcher is currently stateless [1] so you can just create a new instance inside the CrashReporter. The other change that will need to be made is that we can't access ThreadUtils from the CrashReporter so we'll have to have the dispatcher create it's own thread & handler to handle its store events on.

[1]: But I'm afraid some change will be made and that won't always be the case!

	Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]
	Comment 4 • 8 years ago

(In reply to Michael Comella (:mcomella) from comment #3)
> One caveat is that I didn't consider how the dispatcher would run from
> multiple activities. The Dispatcher is currently stateless [1] so you can
> just create a new instance inside the CrashReporter.

Alternatively, we could make the Dispatcher a singleton, but there are caveats to that (if it spawns its own thread, who will shut it down? Will it be in the appropriate state when the CrashReporter runs?).

	Georg Fritzsche [:gfritzsche]
	Comment 5 • 8 years ago

(In reply to Mark Finkle (:mfinkle) from comment #0)
> Once we start sending the pings, I want to import the data into
> Presto/Redash much like we do for events and add-ons. I suppose the data
> could also be imported into crash_aggregates, but I am not familiar with the
> format and how easily that datasource can work with our existing event and
> add-ons data sources.

I guess the interesting question is whether this ping needs to be compatible to the desktop format.
If adding this to crash_aggregates is a goal, it may be useful.

	:Margaret Leibovic
	Comment 6 • 8 years ago

On IRC, mfinkle mentioned that it looks like Fennec is already sending these crash pings somehow:
https://sql.telemetry.mozilla.org/queries/332/source#table

But this rate is way too high, so something is clearly going wrong here.

We should look to see where we could be sending these pings from shared code.

	Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]
	Comment 7 • 8 years ago

re comment 6, Georg, do you know what might be going on here?

	Georg Fritzsche [:gfritzsche]
	Comment 8 • 7 years ago

I updated the query and still see some data:
https://sql.telemetry.mozilla.org/queries/4781/source#9710

The Fennec crash data in that query is presumably coming from the "saved-session" ping, which we send for Fennec opt-in/pre-release users.
Mauro, can you confirm?

	Mauro Doglio [:mdoglio]
	Comment 9 • 7 years ago

The data in crash_aggregates come from a combination of main pings and crash pings. Browser crashes are retrieved from crash pings, everything else from main pings. As a consequence, crash_aggregates only reports browser crashes for Fennec.

	Firefox Bug Husbandry Bot
	Comment 10 • 6 years ago

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

	BMO Automation
	Comment 11 • 3 years ago

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.