Offline caching improvements - Delay between and backoff when 429 is on

[bruno-garcia]

Description

The SDK guideline has a couple of new items regarding offline caching: https://github.com/getsentry/develop/pull/509

1. If rate-limit was hit, make sure the caching transport is aware. Meaning: don't read all files from disk to send to the HTTP transport when that's basically dropping everything due to rate-limit
2. Add a delay when reading from disk to avoid bursts of events which could trigger rate limit
3. Once the device is back online, read events preciously cached (as opposed to send only on restart or when a new event is captured)

Relates to:

• https://github.com/getsentry/sentry-dotnet/issues/1504
• https://github.com/getsentry/sentry-java/issues/1926

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[philipphofmann]

If rate-limit was hit, make sure the caching transport is aware. Meaning: don't read all files from disk to send to the HTTP transport when that's basically dropping everything due to rate-limit

I think one central point of rate-limiting is that if one is active, we should read all files from disk and throw them away. Otherwise, we going to hit another rate limit the next time we try to send all envelopes. @marandaneto, do you agree?

[marandaneto]

we should read all files from disk and throw them away.

I don't think we should throw them away, the comment is about making the transport aware that there's rate limiting going on, so you should back off for a while and don't even try to read/send them for a while.

[philipphofmann]

we should read all files from disk and throw them away.

I don't think we should throw them away, the comment is about making the transport aware that there's rate limiting going on, so you should back off for a while and don't even try to read/send them for a while.

The envelopes could pile up if you keep them in the cache while a rate limit is active. Once the rate limit times out, the SDK could spam the server with the piled-up envelopes, leading to another rate limit. Then you end up in a vicious cycle. See [dev docs](Events, transactions, sessions, and/or any other supported payload type, depending on the communicated limits, are to be discarded during the period that the rate limit is in place.)

Events, transactions, sessions, and/or any other supported payload type, depending on the communicated limits, are to be discarded during the period that the rate limit is in place.

@marandaneto