document ignore_errors

[biblicabeebli]

The old raven library had this functionality, implemented for Django by declaring a list of names of errors in the settings file.

This kind of functionality is necessary to control error reporting spam.

[eth3lbert]

There is a ignore_errors options.

[biblicabeebli]

Could you please link to the documentation for this feature? I have been finding the updated documentation for the new library frustratingly scant in its cross linkings, and laking in details that the older, mature raven library's documentation did contain.

[untitaker]

@biblicabeebli we will add this. I'll keep this issue open as reminder

[untitaker]

@biblicabeebli FWIW we decided not to stabilize ignore_errors for now, in the sense that you can still use it right now but we want to encourage people to use before_send for this instead: https://docs.sentry.io/learn/filtering/?platform=python#before-send

Concretely we eventually want to use the same syntax for ignore_errors that you can use in the project settings on sentry.io, such that it works the same everywhere.

[biblicabeebli]

I understand the urge to centralize an inherently scattered feature - integration with every framework/library requires a custom blob of code to extract the configuration correctly - but I strongly disagree with what sounds like a decision to drop probably the most basic necessary feature beyond "does it work" in an error reporting/monitoring framework.

Asking someone to write their own code to handle this particular issue is silly. This is an error reporting platform. The literal first thing we encountered was "oh, error X is garbage and for Capital-R Reasons we can't disable or squash it, but we don't want that particular one spamming us, how do I disable it..." This cannot possibly be an edge case.

The above should be sufficient reason to stabilize the feature, but if its not...

This is an error reporting and monitoring framework. If I can't block a thing at its source - because sometimes its just not possible to block a thing in the Sentry website's UI because it varies just slightly too much - then cannot use the service to monitor my servers. Too many false negatives. I'm going elsewhere.

[untitaker]

what sounds like a decision to drop probably the most basic necessary feature

There is no decision yet. Stabilizing ignore_errors is in our internal backlog, but we don't know how important it is to people. In that sense, thanks for your feedback.

In any case we should come up with something that works the same across SDKs. Meanwhile you can do the same thing with before_send (for people who come across this issue from Google)

import sentry_sdk

def before_send(event, hint):
    if 'exc_info' in hint:
        exc_type, exc_value, tb = hint['exc_info']
        if isinstance(exc_value, (IgnoredErrorFoo, IgnoredErrorBar)):
            return None
    return event

sentry_sdk.init(before_send=before_send)

because sometimes its just not possible to block a thing in the Sentry website's UI because it varies just slightly too much

I mean, generally this seems like an issue on its own: That sentry is generating multiple issues for a thing you consider to be a single issue.

Just mentioning this for completeness, since it generally seems to be an underused feature: If that's the only reason why you can't send those events in the first place, consider setting a custom fingerprint for that error class (using before_send). Then those errors are grouped together and you can snooze/ignore that one issue. The nice(r) thing about this is that it doesn't require a deploy, can be undone, the data is still always there if you need it.

Sure, if you'd be over quota with those events then it's not an option and you need to block the data before.

[koreno]

Just arrived here since I was looking for this feature.
Will use the before_send, however it is indeed more error prone and less friendly.
Please prioritize the ignored_errors solution!

[kylebebak]

In agreement with @biblicabeebli . This is the first thing I want to configure after getting Sentry set up.

Thanks for the work-around with before_send. More flexible, not as friendly. I would have been happy if this feature, and its function in the context of ignoring exceptions, were better documented, and I'm sure I speak for other users as well.

Just my two cents: implementing something roughly equivalent to the old ignore_exceptions in some cross-platform way should be a top priority.

[rnegron]

"Stabilizing ignore_errors is in our internal backlog, but we don't know how important it is to people. In that sense, thanks for your feedback."

It's very important, imo. As others have said, please prioritize this implementation! We are using the before_send fix for now.

[feakuru]

If I may put my two cents in, I'd say that ignore_errors/before_send seems like a positive case of scattered functionality if there may ever be one. It seems to me that the most user-friendly way to implement this would be to disallow simultaneous usage of these options and have ignore_errors be the shortcut for writing a before_send with a conditional return None. Just an idea for you guys ☺️

[mrtarunjain]

I used the workaround of before_send provided in my Flask app. But it didn't work for me as I did not get 'exc_info' in the hint.

Here is event variable data:

'logentry': {'message': '400: error: app_code key is missing: None', 'params': ()}

Please help!

[untitaker]

@mrtarunjain this event is not an exception. It likely contains a logger name. Your best bet is to filter out that logger. I think you want https://docs.sentry.io/platforms/python/logging/#ignoring-a-logger

[crccheck]

Sorry for the tangent but this came up in a Google search

FWIW we decided not to stabilize ignore_errors for now, in the sense that you can still use it right now but we want to encourage people to use before_send for this instead: https://docs.sentry.io/learn/filtering/?platform=python#before-send

It's not in the documentation, but to get the same effect as ignore_errors, instead of return event, make your before_send do return None

sentry-python/sentry_sdk/client.py

Lines 152 to 155 in d25fba8

	with capture_internal_exceptions():
	new_event = before_send(event, hint)
	if new_event is None:
	logger.info("before send dropped event (%s)", event)

[trondhindenes]

so much this. The ability to disable exception reporting on abort(404) in flask is what I would consider absolutely basic functionality (and it worked fine in the raven package). It would be great if these scenarios were properly implemented and documented so all could benefit instead of each org having to write their own exclusion logic.

[WhyNotHugo]

Is there any working example of how to ignore a single error? The old SDK implemented this very basic functionality just fine, I don't get why it got dropped, I feel the new SDK is a huge step back compared to the previous one (since it just dropped functionality but didn't add anything new).

The documentation says:

import sentry_sdk

def strip_sensitive_data(event, hint):
    # modify event here
    return event

sentry_sdk.init(
    before_send=strip_sensitive_data
)

However, the "modify event here" code is unknown, and we're left to guess it. The event and hint parameters are not documented anywhere, so we have to reverse engineer the SDK to figure out how it works (if we're supposed to use this method, please document its parameters).

There's another example in the docs which just won't work because it references entries that the hint dictionary doesn't have:

hint dict:

{'log_record': <LogRecord: py.warnings, 30, /usr/local/lib/python3.8/warnings.py, 109, "%s">}

Also, this doesn't have the exc_info set (the library that's raising the warning is simply not including it):

>>> hint['log_record'].exc_info == None
True

Meanwhile, the event dictionary is about 32k of data which I can't make heads of tails out of. It seems to include all the runtime information about my app.

Can we have a working example of how to ignore a single type of event based on the exception/warning class?

[untitaker]

@WhyNotHugo This issue is about ignoring exception classes while you seem to want to ignore a warning class. To my knowledge the Raven SDK did not provide any simple configuration option to ignore warnings by class. It doesn't really help that Django has logger names such as DisallowedHost that look like exception classpaths, but this is nothing new and has little to do with Sentry.

I am really curious as to what's going on here, as it seems that you have configured the SDK to send each warning log as event to Sentry, possibly using the API documented as part of the logging integration. That seems generally excessive and is certainly not the default of the SDK.

I would encourage you to open a new issue about this as the idea of ignoring a warning class is very different from what we're discussing here and there seems to be more going on here than what fits into either feature request.

[untitaker]

Also feel free to hop onto the Discord linked in the README as you've opened a couple of issues in the SDK that indicate you're having a especially bad time migrating. I would be curious as to how your Raven configuration looked and what kind of errors you were used to get.

[WhyNotHugo]

Aren't warning/errors handled pretty much the same?
Or are they having different behaviours for me due to how I have sentry set up?

I am indeed logging warnings, since I generally want to be aware of any that might occur on production.

init_sentry(
    attach_stacktrace=True,
    before_send=before_send,
    integrations=[
        CeleryIntegration(),
        DjangoIntegration(),
        LoggingIntegration(event_level=logging.WARNING),
    ],
    release=version,
    in_app_exclude=["logging"],
)

So hint would have the exc_info attribute only for exceptions? (again, this parameter is completely undocumented).

[untitaker]

The two questions "error vs warning" and "exc_info vs not" are completely orthogonal:

# Sentry error event without stacktrace or exception
# "exc_info" not in hint
# hint["log_record"].exc_info is None
logging.error("random error logged, but no exception")

try:
    1/0
except:
    # Sentry "warning" event with an exception and stacktrace attached
    # hint["log_record"].exc_info is not None
    # hint["log_record"].exc_info is hint["exc_info"]
    logging.warning("failed to divide by zero", exc_info=True)

This data model is part of the logging library and, for lack of a better word, not Sentry's fault. By default only the error is sent as event, and we make that decision purely based on the event_level.

Full acknowledgement that hints are poorly documented.

EDIT: Not sure, but this page does link to https://docs.sentry.io/platforms/python/#hints

[WhyNotHugo]

Oh, many of my warnings are actually warnings.warn("deprecated", DeprecationWarning..., so there is an actual "exception class".

However, since they're third part libs (or even stdlib), I can't jump in and add exc_info=True.

[untitaker]

Okay we don't regard that as exception though. I think this would be a good addition though, to be able to filter by warning class

[untitaker]

@gotedkid195 please read the thread first. your question is answered in it.

[gotedkid195]

@untitaker you mean use

import sentry_sdk

def strip_sensitive_data(event, hint):
    # modify event here
    return event

sentry_sdk.init(
    before_send=strip_sensitive_data
)

to reslove my issue.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[antonpirker]

A quick tl;dr:

• In the old Python SDK (called Raven) there was a option ignore_errors where one could give a list of error classes to init() that should not be sent to Sentry.

• In the new Python SDK (called sentry-python) the option ignore_errors does NOT exit.
  In the new Python SDK you can specify a before_send callback where you can filter out events. So filtering by error class is now done like this:

  import sentry_sdk
  
  def before_send(event, hint):
      if 'exc_info' in hint:
          errors_to_ignore = (IgnoredErrorFoo, IgnoredErrorBar)
          exc_value = hint['exc_info'][1]
  
          if isinstance(exc_value, errors_to_ignore):
              return None
  
      return event
  
  sentry_sdk.init(before_send=before_send)