Configuration options for memory warnings?

[shagedorn]

Question

As of v2.15.0, iOS memory warnings are automatically tracked as RUM errors.

While I love the idea of tracking them as context of (potential) other problems down the road, I'm not sure if a memory warning itself should count as a RUM error (especially if the app responds accordingly by releasing memory).

We're worried of getting flooded with tons of memory warnings, and many of them may not be actionable, since they also heavily depend on the device and usage (e.g., something else running in the background,…). In other words, receiving a memory warning may or may not have anything to do with our app, although it does have a potential impact on it.

Shouldn't these be tracked as something else other than an error? We have not found any way to configure/disable those, and are currently holding back on SDK updates for this reason.

Would love to hear the reasons for making them RUM errors, and also hear from others who have already adopted v2.15.0 or later how this looked in production.

[ganeshnj]

Hi @shagedorn,

For background, the addition of memory warnings is part of our ongoing effort to improve error tracking. Since we began detecting watchdog terminations—which often lack sufficient details to take actionable steps—developers can now make more educated guesses that a termination may be related to a memory issue (most commonly OOM).

The experience is similar for app hangs, fatal app hangs, WT, and memory warnings. If the dashboards become too noisy, you can always filter out the unnecessary details.

However, having a configuration option is a reasonable ask, which we are discussing internally. We will update the issue with further details as we progress.

[shagedorn]

Thanks a lot for your prompt reply!

developers can now make more educated guesses that a termination may be related to a memory issue (most commonly OOM).

That totally makes sense and is absolutely appreciated 🙏🏻 I just feel that the memory warning itself isn't semantically an error, and it may raise unnecessary alarm bells when non-iOS-engineers notice them.

This may of course be more of a long-term ask (because it probably cannot be solved just within the iOS SDK), but maybe RUM needs more "primitives" than we currently have (errors, actions, screen views,…). I think being able to report a "RUM warning" or maybe just a neutral piece of information (similar to an action or screen view) would be beneficial, to keep a semantical and terminological difference between actual problems (= errors) and additional context for debugging them (like memory warnings).

However, having a configuration option is a reasonable ask, which we are discussing internally. We will update the issue with further details as we progress.

Thank you! 🙂

[ganeshnj]

After discussion, we think think to not have configuration for it given the fact you can filter the events quite easily.

This is not one way door, If we get more such requests or community feedback then we can definitely look at it again.

Closing for now.

[shagedorn]

We have updated the SDK now and noticed these "errors" even include stacktraces. Please give us an option to turn this off. Again, a memory warning may be completely unrelated to what our app does, and creating and sending a full stacktrace is excessive in our opinion – it could actually make it worse, given all of this happens at a time when iOS asks us to relinquish resources.

[rohdester]

Yeah, not a fan of this. How can I exclude these from our logs?

[fabioferrero]

To be honest, Memory Warnings are, as the name suggests, warnings, not errors. It's not correct to track them as errors and we should be able to see them in the console with a different warning severity.

[shagedorn]

Indeed. They should be RUM events or something similar. Our app has now uploaded many thousands of those "errors", all with the exact same stacktrace, because it's always just describing how a memory warning arrives on iOS. It's completely senseless CPU and network effort on our users' devices. Please allow us to stop this @ganeshnj.

[fabioferrero]

@ganeshnj , can you considerate reopening this issue? Thanks 🙏

[ncreated]

Thanks for the additional feedback, @shagedorn, @rohdester, and @fabioferrero. Based on your input, we’ve gathered enough evidence to reconsider our approach to handling memory warnings. We’ve decided to introduce an API that will allow you to better control and disable this feature. We've added this to our backlog and will prioritize it accordingly.

[shagedorn]

Thanks @ncreated, we appreciate your response and action! 🙏🏻