Sending cached events periodically

[nominalista]

Because some of the events may be not be sent immediately after they are created, it would be great if there was an option to send these events periodically, even if the app is not restarted.

Is there any method in SDK that I can call and try to send cached events? I would use it as a temporary solution along with e.g. WorkManager.

[marandaneto]

as agreed, I'll mark it as a feature request, thanks @nominalista
related to getsentry/sentry-android#360

[nominalista]

Thanks @marandaneto. Just to be sure - are you considering the whole periodic mechanism or only method that would allow to send cached events? If whole mechanism, is such method already existing?

[marandaneto]

the mechanism to send periodically is something to be done, this is the feature request.
the method to send cached events are already in place as mentioned in getsentry/sentry-android#360 SendCachedEventFireAndForgetIntegration
https://github.com/getsentry/sentry-android/blob/master/sentry-core/src/main/java/io/sentry/core/SentryOptions.java#L817

If you use this integration periodically, it'd work, but it might be racey, be aware of that.

[nominalista]

Ok, thank you!

[jadbaz]

@marandaneto, how is it possible to use the integration periodically (as you mentioned in your last comment)?

[marandaneto]

this issue isn't Android specific, hence removing the Android label

[marandaneto]

@jadbaz this feature isn't supported yet, I'd prefer to not share a hacky solution with flawns, please upvote the issue, and let's see if we can get prioritized.

[jadbaz]

Hello,
Just checking up if this is on the roadmap at some point

[ghost]

I think this is really important for client apps and I'm also waiting for this.

[bruno-garcia]

We've expanded the offline caching feature guidelines further: https://develop.sentry.dev/sdk/features/#buffer-to-disk

Relates to: getsentry/sentry-dotnet#1504

[marandaneto]

It'd benefit when you have an unstable connection, or no connection at all.
Events are always sent on restart anyway.
Also when you never close/kill the app very often, the OS does it anyways when memory is needed.

The next step would be to implement an improvement already made by the Sentry Cocoa SDK, which is sending every pending envelope once an envelope is captured.
So if you capture an envelope and you have no connection, the envelope is cached, if you capture another envelope and there's connection, both envelopes would be sent.

How does that sound?

[vibin]

@marandaneto FWIW, I like that Sentry doesn't use WorkManager/AlarmManager, etc. to auto-initialise background jobs for sending cached events – because, I have a usecase where I initialise Sentry conditionally (only if a feature flag is on).

I see that currently SendCachedEnvelopeFireAndForgetIntegration is the class that is responsible for pushing cached events on app initialisation, so it's working well for my usecase

[farfromrefug]

I am very interested with such a feature. One thing that could be done to help apps is to implement the io.sentry.Sentry.flush method. Wondering if this could be done by using this https://github.com/getsentry/sentry-java/blob/469420402e4717906783a744f8e2fb156168ec25/sentry/src/main/java/io/sentry/SendCachedEnvelopeFireAndForgetIntegration.java

[markushi]

After some discussion we're considering to close this in favor of:

1. Send cached and pending envelopes when an envelope is going to be sent #1932
2. Observing for network changes and resend any uncached envelopes (Offline caching improvements - Delay between and backoff when 429 is on #1926)
3. (Optional) Allow manually triggering this, aka extending Sentry.flush()

@farfromrefug Given that we'll implement 1 and 2, would you still be interested in having a manual (3) option?

[farfromrefug]

@markushi if possible yes that would be good I think. The case I see is a failure to send on envelop added (like server down or error) and then the app would like to force a "try again"

[romtsn]

Let's create a new issue dedicated to providing manual API for force-flushing pending envelopes and close this one. @markushi

[markushi]

Closing this in favor of #2920, please upvote the issue to give it more priority!