Recursive serializer stackoverflow error when serializing an object that logs on iteration

[alexmick]

I'm currently having a problem with the SDKs integrated serialisation of local variables for sending with events. I have in my local variables, an object that is a Mapping but that sometimes raises an event when keys are accessed. This is a normal behavior, since keys are lazy loaded and my code handles these correctly. However, when an event occurs and this variable is serialized for sending to sentry, the sdk iterates over all my keys and causes an infinite recursion.

Minimal code te reproduce :

import logging
from collections.abc import Sequence
import sentry_sdk

logger = logging.getLogger(__name__)

class MyGenerator(Sequence):
    def __init__(self):
        self.values = [1, 2, 3]
        Sequence.__init__(self)

    def __iter__(self):
        for value in self.values:
            yield value
        logger.error(f"No values left", exc_info=True)

    def __len__(self):
        """List length"""
        return len(self.values)

    def __getitem__(self, ii):
        """Get a list item"""
        return self.values[ii]

if __name__ == "__main__":
    sentry_sdk.init(
        dsn="[DSN]"
    )

    gen = MyGenerator()

    logger.error("Testing", exc_info=True)

The only quick solution I found is to set with_locals=False on the sdk but it's a pity to lack all this functionality because of this case. On the other hand, I'm not sure how the SDK could anticipate such problems, here's what I'm thinking:

• The SDK could check how deep in recursion it is when serializing and stop when it notices it's handling a log that was generated while handling an other log.
• In the same way that exceptions that occur when deserializing trigger <failed to serialize, use init(debug=True) to see error logs>, all logs could be disregarded
• In some cases it could be problematic that sentry iterates over those variables altogether (for example, emptying a generator when it should still have values available) and for those maybe a serialize_ignore_classes=[MyDangerousClass] on the SDK init could avoid interference with such classes.

Happy to open a PR to follow-up on this when a proper solution is found !

[untitaker]

Thanks, this will be fixed with #470. All events captured during serialization are disregarded. The logs still show up in breadcrumbs.

There is already a semi-private hook called global_repr_processors that you can use to customize serialization of dangerous objects.