[SR] Disable replay in session mode when rate limit is active

[romtsn]

📜 Description

• Add mappings for DataCategory <-> ItemType to make replays respect rate-limiting
• Check if rate-limiting is active for Replays or All before recording a screenshot in session mode to not consume disk space. In session mode we capture segments every 5s so if a rate limit is active for e.g. 10 minutes we'd quickly overflow the envelope cache with replay segments. In buffer mode, however, it's still fine to capture the replay because it'll be only one envelope that we store if an error occurs.

💡 Motivation and Context

Part of getsentry/sentry#74441

💚 How did you test it?

Manually + automated

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

• sentry/src/main/java/io/sentry/transport/RateLimiter.java

[github-actions]

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

• sentry/src/main/java/io/sentry/transport/RateLimiter.java

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	392.38 ms	452.42 ms	60.04 ms
Size	1.70 MiB	2.35 MiB	668.54 KiB

[philipphofmann]

@brustolin and @romtsn I think this is a different behaviour than on iOS getsentry/sentry-cocoa#4496. On iOS, when a limit for SR gets active, we drop everything until the next session starts. Please align.

[brustolin]

Yes, in our last replay meeting, we agreed to start with the basics and stop session replay altogether for the remainder of the app session.

[romtsn]

I think it'd be more work for me to stop the entire replay than just not recording screenshots tbh. Besides, what if rate-limit is active for let's say 30seconds when we''re just starting the replay and because of that we're going to drop the entire replay? i'd prefer to do our best and start capturing from when the rate-limit is lifted?

[philipphofmann]

i'd prefer to do our best and start capturing from when the rate-limit is lifted?

That's also my opinion. This would also simplify the logic.

[brustolin]

But your current logic is not taking into account that the envelope with segment 0 could be the one that was lost. It does not matter anymore to send to following segments, they all will be ignored in the server.

[brustolin]

Btw, this approach is just throwing away the already-taken screenshot. Maybe Android is different; for iOS, making the screenshot is the most expensive part of the process.

[brustolin]

Another point to take into account, someone can correct me on this one, is that the most common form of rate limiting is quota exceeded. And this will only be lifted at the end of the month.

[romtsn]

But your current logic is not taking into account that the envelope with segment 0 could be the one that was lost. It does not matter anymore to send to following segments, they all will be ignored in the server.

Why would it be lost? We're not capturing envelopes if rate limit is active right? Or do you mean if we get rate-limited upon sending the segment 0 event? In this case on Android it'd be stored in cache until rate-limit is lifted. The only case it gets lost if the cache gets rotated, but it's an edge-case enough to not handle it for now I guess.

Btw, this approach is just throwing away the already-taken screenshot. Maybe Android is different; for iOS, making the screenshot is the most expensive part of the process.

That's a good point, I should probably move this logic to where we capture the screenshot 👍

Another point to take into account, someone can correct me on this one, is that the most common form of rate limiting is quota exceeded. And this will only be lifted at the end of the month.

Probably yes, but not sure about the end of the month (could be on-demand events etc etc). I think this is also mostly relevant for big customers who have spike protection and whatnot in place, so we shouldn't think in "months" here probably :)

[philipphofmann]

And this will only be lifted at the end of the month.

Nope, spike protection works on an hour basis: https://docs.sentry.io/pricing/quotas/spike-protection/#how-sentry-detects-spikes

[philipphofmann]

I don't have enough insight into SR. I let you two decide this.