Open Bug 1792912 Opened 2 years ago Updated 2 years ago

Add component or module tags to Sentry reports

Categories

(Fenix :: Crash Reporting, task, P3)

All
Android
task

Tracking

(Not tracked)

People

(Reporter: csadilek, Unassigned)

Details

From github: https://github.com/mozilla-mobile/android-components/issues/6578.

In many cases we can determine, or at least make a good educated guess, from which component or application module a report originated.

For example, by looking at the specific exception type in the following report, we can determine where this originated from and add a module: app-services tag.

mozilla.appservices.places.PlacesException: Error executing SQL: database or disk is full
    at mozilla.appservices.places.RustError.intoException(RustError.kt:4)
    at mozilla.appservices.places.PlacesWriterConnection.noteObservation(PlacesConnection.kt:12)
    at mozilla.components.browser.storage.sync.PlacesHistoryStorage$recordObservation$2.invokeSuspend(PlacesHistoryStorage.kt:11)
    at mozilla.components.browser.storage.sync.PlacesHistoryStorage$recordObservation$2.invoke(PlacesHistoryStorage.kt)
    at kotlin.jvm.internal.Intrinsics.startUndispatchedOrReturn(Intrinsics.java:2)
    at kotlin.jvm.internal.Intrinsics.withContext(Intrinsics.java:9)
    at mozilla.components.feature.session.HistoryDelegate.onTitleChanged(HistoryDelegate.kt:7)
    at mozilla.components.browser.engine.gecko.GeckoEngineSession$createContentDelegate$1$onTitleChange$$inlined$let$lambda$1.invokeSuspend(GeckoEngineSession.kt:5)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:2)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:19)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:14)

And in the stack trace below, which has a generic Java exception, we can look at the stack trace and see that the first package that we own is mozilla.telemetry.glean so this could have a module: glean tag attached.

java.util.concurrent.TimeoutException: mozilla.telemetry.glean.private.CounterMetricType.finalize() timed out after 10 seconds
    at com.sun.jna.Native.invokeVoid(Native.java)
    at com.sun.jna.Function.invoke(Function.java:98)
    at com.sun.jna.Function.invoke(Function.java:22)
    at com.sun.jna.Library$Handler.invoke(Library.java:27)
    at java.lang.reflect.Proxy.invoke(Proxy.java:397)
    at $Proxy1.glean_destroy_counter_metric
    at mozilla.telemetry.glean.private.CounterMetricType.finalize(CounterMetricType.kt:2)
    at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:209)
    at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:192)
    at java.lang.Thread.run(Thread.java:818)

I think with some simple logic we can probably classify quite a few reports in more detail. And that will allow us to create better dashboarding in Socorro and Sentry.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cpeterson)
Severity: -- → N/A
Type: defect → task
Priority: -- → P3
Flags: needinfo?(cpeterson)
You need to log in before you can comment on or make changes to this bug.