fix(logging): Strip log record.name for more robust matching

[romaingd-spi]

Hi! In the Python SDK, more specifically sentry_sdk/integrations/logging.py, a couple of loggers are ignored to avoid recursion errors.

_IGNORED_LOGGERS = set(
    ["sentry_sdk.errors", "urllib3.connectionpool", "urllib3.connection"]
)

Log records from these loggers are discarded, using an exact match on record.name. Unforunately, this breaks if the user modifies record.name, e.g. for formatting, which is what we were doing for log display (before becoming aware that Sentry relied on it after investigating an infinite recursion issue).

class _LengthFormatter(logging.Formatter):
    def format(self, record):
        """
        Format a log record's header to a constant length
        """
        if len(record.name) > _MAX_LOGGER_NAME_LENGTH:
            sep = "..."
            cut = _MAX_LOGGER_NAME_LENGTH // 3 - len(sep)
            record.name = record.name[:cut] + sep + record.name[-(_MAX_LOGGER_NAME_LENGTH - cut - len(sep)) :]
        record.name = record.name.ljust(_MAX_LOGGER_NAME_LENGTH)

        record.levelname = record.levelname.ljust(_MAX_LOGGER_LEVEL_NAME_LENGTH)
        return super().format(record)

As you can see, record.name is right-padded with blank spaces. We have found a workaround since, but given that it has taken us quite some time to find the issue, I thought that maybe it could affect others. This PR proposes matching record.name.strip() instead for increased robustness.

[szokeasaurusrex]

I think this seems like a fair thing to do.

However, I would still recommend you avoid modifying the LogRecord's name in the formatter for the best experience when using Sentry. The (unstripped) name gets sent to Sentry, and we use it in some other conditional checks which you have not updated in this PR. I have never written a logging formatter before, but my guess is that it is probably best practice to not mutate the log record at all in the formatter, and instead just read the attributes from it and format it directly into a string.

The PR looks good to me though, I will just have another member of the team review before we merge.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.68%. Comparing base (4420c4d) to head (6b7e41c).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4411   +/-   ##
=======================================
  Coverage   80.68%   80.68%           
=======================================
  Files         142      142           
  Lines       15986    15986           
  Branches     2732     2732           
=======================================
+ Hits        12898    12899    +1     
  Misses       2231     2231           
+ Partials      857      856    -1     

Files with missing lines	Coverage Δ
sentry_sdk/integrations/logging.py	82.69% <100.00%> (ø)

... and 1 file with indirect coverage changes

[romaingd-spi]

Thank you for your review!

However, I would still recommend you avoid modifying the LogRecord's name in the formatter for the best experience when using Sentry. The (unstripped) name gets sent to Sentry, and we use it in some other conditional checks which you have not updated in this PR. I have never written a logging formatter before, but my guess is that it is probably best practice to not mutate the log record at all in the formatter, and instead just read the attributes from it and format it directly into a string.

Agreed! Once we identified the issue, we reached a similar conclusion that treating the record name as immutable was a much better practice, both for the Sentry integration and overall, and we have since changed the formatter accordingly. Still, if we have fallen into that trap, maybe others will too.

I see that a couple tests are failing in CI checks, apparently all due to a fixture 'event_loop' not found error in aiohttp tests. I don't think it's related to my PR, and I don't have the rights to re-run tests, but let me know if there's something I can do.

[sentrivana]

Thanks for the PR @romaingd-spi! The test failures were unrelated and should now be fixed on master. I've merged master into your branch so we should be green. If that's the case we'll merge!