Decouple SentryAndroid initialisation from Events sending

Discussed in #1751

^{Originally posted by PGliw October 4, 2021}
SentryAndroid does call installDefaultIntegrations in init Method.
There are some integrations included that are not "the best" choice for my use case.
(SendCachedEventFireAndForgetIntegration and EnvelopeFileObserverIntegration I suppose).

The workflow I do want to achieve is following (assuming #1739 is closed by the time):

First, init SentryAndroid framework, so breadcrumbs are collected
Do not send any events automatically!
Check if there was a crash during last app run
If there was, ask the user what to do with the crash event
If the user wants to send the cached event, send it. Otherwise just delete the event from the cache.

Sadly, because of coupling SentryAndroid.init with SendCachedEventFireAndForgetIntegration, the crash reports are being sent once the app was started after crash. So it's impossible to achieve step 2. having done step 1., isn't it?
Could the initialisation of the framework (that is initialisation of collecting breadcrumbs etc.) be decoupled from sending the cached events? And could sending the events be made "on-demand"?

I assume it's impossible because of coupling SendCachedEventFireAndForgetIntegration integration's register method to submitting sending tasks, isn't it? And there is no clean way to enable/disable it on demand.

It might be way of doing it by implementing custom TransportGate, but how to invoke SendCachedEventFireAndForgetIntegration later, once we need to send the event? (see point 5.)

Also sending the crash event should not be done after the crash, by on-demand on the next start of the app (UncaughtExceptionHandlerIntegration seems to do the opposite by default?)

Hi, thanks for raising this issue.

Indeed, right now this is not possible, and it's not Android-specific, I'll discuss this internally and will let you know asap, thanks.

Thank you for your answer, I am waiting for hearing from you then 👍

@marandaneto

@marandaneto Thank you for looking into this and discussing this internally! For the current version, is there at least any way to know if the automatic sending of cached app crashes (envelopes) is ended?
I suppose (based on SendCachedEnvelopeFireAndForgetIntegration name and @SuppressWarnings("FutureReturnValueIgnored")) that is not possible?
So calling

SentryAndroid.init(context) { .... } // 1
Sentry.flush(...) // 2
// 3 here I assumed the sending is ended, but apperantelly it's not

Am I right?
So I have basically two issues with SendCachedEnvelopeFireAndForgetIntegration:

it sends the by initialisation (coupling initialisation with sending)
it does not let you know when sending is finished
Is there any way to solve the second problem without removing the default SendCachedEnvelopeFireAndForgetIntegration and writing my own?

@PGliw Sentry.flush only flushes what's in memory, so events are not lost.

no, there's no way afaik, that's how the SDK was designed, it's purposely coupled.

I believe we can be flexible to support both use cases, but the main use case should be as it is, since we'd like to send events as soon as possible, maybe users never open the App again, maybe they uninstall the App, and events won't be reported.

Sounds like a user consent feature, which we plan on introducing but will require a large change and still needs to be prioritized.

We're going to create a new issue with a more detailed description of user consent.

Closed in favor of #1988

Navigation Menu

Repository navigation

Decouple SentryAndroid initialisation from Events sending #1752

Discussed in #1751

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Decouple SentryAndroid initialisation from Events sending #1752

Description

Discussed in #1751

Activity

marandaneto commented on Oct 5, 2021

pchoroscin commented on Oct 5, 2021

pchoroscin commented on Oct 5, 2021

marandaneto commented on Oct 7, 2021

bruno-garcia commented on Oct 27, 2021

marandaneto commented on Apr 13, 2022

marandaneto commented on Apr 13, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions