kiwicom/structlog-sentry

Potential problem with `sentry-sdk` 1.23.0

Closed this issue · 4 comments

Getting this KeyError suddenly when sentry-sdk was upgraded to 1.23.0.

Traceback (most recent call last):
  File "/app/venv/lib/python3.10/site-packages/structlog_sentry/__init__.py", line 168, in _handle_event
    event, hint = self._get_event_and_hint(event_dict)
  File "/app/venv/lib/python3.10/site-packages/structlog_sentry/__init__.py", line 119, in _get_event_and_hint
    event, hint = event_from_exception(
  File "/app/venv/lib/python3.10/site-packages/sentry_sdk/utils.py", line 1038, in event_from_exception
    "values": exceptions_from_error_tuple(
  File "/app/venv/lib/python3.10/site-packages/sentry_sdk/utils.py", line 913, in exceptions_from_error_tuple
    single_exception_from_error_tuple(
  File "/app/venv/lib/python3.10/site-packages/sentry_sdk/utils.py", line 729, in single_exception_from_error_tuple
    include_source_context = client_options["include_source_context"]
KeyError: 'include_source_context'

Sentry SDK introduces this line in this PR, released in 1.23.0.

Experiencing the same issue here, this silently fails when calling log.exception or log.error(..., exc_info=True) resulting in no exception being sent to Sentry. Downgrading to 1.22.x works.

This also effected me.

It appears to be a similar issue to #112
where the client_options dictionary supplied to event_from_exception does not contain keys sentry-sdk expects.

Is there a reason structlog-sentry constructs its own client_options dict, rather than just using hub.client.options directly which is what sentry-sdk appears to do internally,
e.g. here do

options = self._get_hub().client.options
event, hint = event_from_exception(
    exc_info,
    client_options=options,
)

that might prevent future issues like this from occurring.

Sorry for the slow response. I think what @LincolnPuzey is suggesting makes sense. I'll open a PR.

I hope it is fixed now (version 2.0.3). I was testing it and seems that @LincolnPuzey suggestion resolves the issue (and it also removes the need to check SDK version for compatibility - I'm kind of surprised we missed this solution from the beginning).