Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

romaingd-spi
Copy link

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.

@romaingd-spi romaingd-spi requested a review from a team as a code owner May 21, 2025 15:16
Copy link
Member

@szokeasaurusrex szokeasaurusrex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

codecov bot commented May 26, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.59%. Comparing base (385c668) to head (c76fc10).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4411      +/-   ##
==========================================
- Coverage   80.61%   80.59%   -0.03%     
==========================================
  Files         142      142              
  Lines       15973    15973              
  Branches     2727     2727              
==========================================
- Hits        12877    12873       -4     
- Misses       2240     2241       +1     
- Partials      856      859       +3     
Files with missing lines Coverage Δ
sentry_sdk/integrations/logging.py 82.80% <100.00%> (ø)

... and 2 files with indirect coverage changes

@romaingd-spi
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants