Failed events are not respecting retryInterval option

[AlexanderEggers]

When an event cannot be send due to an network/server or whatever reason, the sdk will retry sending the event every second and never seems to stop.

• analytics-react-native version: v2.1.3-beta
• React Native version: 0.67.2
• iOS or Android or both? both

Steps to reproduce

• Use a default project template
• Add segment
• Have the network call fail due to missing vpn connection or similar which creates a TypeError: Network request failed error.

Expected behavior

• Failed events should respect the retry interval

Actual behavior

• Failed events retry is after 1 second instead of using the 60 second default interval.

[alanjcharles]

thanks @AlexanderEggers will take a look today!

[oscb]

Hi @AlexanderEggers, retryInterval is actually an old deprecated option. (We should have removed it before, sorry for the confusion)

The way it works is that the events that failed are left in the queue, the options flushAt and flushInterval apply to them. So they will get sent again when the queue reaches flushAt or the interval triggers. Technically there's no distinction between failed events and new events added in the queue.

[AlexanderEggers]

In that case I'm wondering how to ease the pressure on the app when one event fails and there are 1000 (and more retries) within a few seconds - that doesn't seem correct to me. I would expect failed to be retried after some time but not instantly after a few ms.

[oscb]

Can you share us the configuration you use for the client object? Provided the `flushAt` and `flushInterval` are not too low that’s definitely not expected.

…

On Feb 23, 2022, 14:05 -0800, Alexander Eggers ***@***.***>, wrote: In that case I'm wondering how to ease the pressure on the app when one event fails and there are 1000 (and more retries) within a few seconds - that doesn't seem correct to me. I would expect failed to be retried after some time but not instantly after a few ms. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[AlexanderEggers]

I left these values as their default values - these are not set by me at the moment.

[oscb]

Thanks! I just submitted a fix for the interval logic, this should fix the issue you're seeing

[AlexanderEggers]

When do you think that will land as a release? That fix is quite important in regards to device performance.

[oscb]

I will release this tomorrow. There was one minor problem in the CI tests today.

[AlexanderEggers]

@oscb Do you think you will have chance to publish another release today? Just planning another internal release of a project and would be really keen to get these changes as part of that release.

[oscb]

Yes! It's going out today as v2.1.7 (in a few hours)

[AlexanderEggers]

@oscb I just found an edge case where that is still not respecting the retryInterval. If the SSL handshake fails to the segment service (when pushing events), the package seems to retry without stopping (even going past 1000 retries without 10 seconds).