segmentio / analytics-react-native

The hassle-free way to add analytics to your React-Native app.
https://segment.com/docs/sources/mobile/react-native/
MIT License
354 stars 182 forks source link

Events fired before app is killed never send – even after re-opening #833

Open ary31415 opened 1 year ago

ary31415 commented 1 year ago

Steps to reproduce Open app, fire some arbitrary analytics events, then kill app before flushAt or flushInterval for segment client is reached. Reopen app.

Expected behavior Backlogged analytics events should be persisted and sent to server as soon as app is reopened – or failing that, along with the next batch of events generated in the new session.

Actual behavior Events from the new session are created and sent as expected, events from the first session are simply lost.

jinsung-kim commented 1 year ago

+1

oscb commented 1 year ago

It is possible this was caused by this import issue that got fixed in Sovran 1.0.3.

Can you upgrade sovran? Make sure to install also @react-native-async-storage/async-storage or use your own persistor.

ary31415 commented 1 year ago

I updated Sovran and this mostly alleviated the issue.

When I kill the app and then reopen it, events are not sent immediately, seeming to be in slight conflict with the README? The doc says "By default, the analytics will be sent ... whenever the app resumes if the user has closed the app with some events unsent.", which is the behavior I observe when I put the app in background and then later resume it – the backlogged events are sent immediately. By contrast, when I kill it and re-open it, there is no immediate batch of events sent.

However, when I do receive a batch of events once the flushInterval is reached, the events from the previous app session are included among them, which is good.

viraj-nikam commented 1 year ago

We are also facing the same issue and even after updating to Sovran 1.0.4, it doesn't seem to alleviate the issue at all. All the events before app kill are lost completely.

liamfd-titan commented 9 months ago

Just wanted to see if there are any updates on this one, we think it may be related to see data issues we've seen since upgrading from 1.x to 2.15.0.

ddemid commented 9 months ago

Same issue here - 2.16.0

dane-thomas-vs commented 7 months ago

Hello, bumping this issue as we are also experiencing this in our application. Manually flushing the event cache after critical events were fired helped alleviate, but I'm hoping for a less manual solution.