Bump sentry-sdk from 0.16.1 to 1.14.0

[dependabot]

Bumps sentry-sdk from 0.16.1 to 1.14.0.

Release notes

Sourced from sentry-sdk's releases.

1.14.0

Various fixes & improvements

• Add before_send_transaction (#1840) by @​antonpirker

  Adds a hook (similar to before_send) that is called for all transaction events (performance releated data).

  Usage:

    import sentry_sdk
  def strip_sensitive_data(event, hint):
  # modify event here (or return None if you want to drop the event entirely)
  return event
  sentry_sdk.init(
  # ...
  before_send_transaction=strip_sensitive_data,
  )

  See also: https://docs.sentry.io/platforms/python/configuration/filtering/#using-platformidentifier-namebefore-send-transaction-

• Django: Always remove values of Django session related cookies. (#1842) by @​antonpirker

• Profiling: Enable profiling for ASGI frameworks (#1824) by @​Zylphrex

• Profiling: Better gevent support (#1822) by @​Zylphrex

• Profiling: Add profile context to transaction (#1860) by @​Zylphrex

• Profiling: Use co_qualname in python 3.11 (#1831) by @​Zylphrex

• OpenTelemetry: fix Use dict for sentry-trace context instead of tuple (#1847) by @​AbhiPrasad

• OpenTelemetry: fix extra dependency (#1825) by @​bernardotorres

• OpenTelemetry: fix NoOpSpan updates scope (#1834) by @​Zylphrex

• OpenTelemetry: Make sure to noop when there is no DSN (#1852) by @​antonpirker

• FastAPI: Fix middleware being patched multiple times (#1841) by @​JohnnyDeuss

• Starlette: Avoid import of pkg_resource with Starlette integration (#1836) by @​mgu

• Removed code coverage target (#1862) by @​antonpirker

1.13.0

Various fixes & improvements

• Add Starlite integration (#1748) by @​gazorby

  Adding support for the Starlite framework. Unhandled errors are captured. Performance spans for Starlite middleware are also captured. Thanks @​gazorby for the great work!

  Usage:

  from starlite import Starlite, get
  import sentry_sdk

... (truncated)

Changelog

Sourced from sentry-sdk's changelog.

1.14.0

Various fixes & improvements

• Add before_send_transaction (#1840) by @​antonpirker

  Adds a hook (similar to before_send) that is called for all transaction events (performance releated data).

  Usage:

    import sentry_sdk
  def strip_sensitive_data(event, hint):
  # modify event here (or return None if you want to drop the event entirely)
  return event
  sentry_sdk.init(
  # ...
  before_send_transaction=strip_sensitive_data,
  )

  See also: https://docs.sentry.io/platforms/python/configuration/filtering/#using-platformidentifier-namebefore-send-transaction-

• Django: Always remove values of Django session related cookies. (#1842) by @​antonpirker

• Profiling: Enable profiling for ASGI frameworks (#1824) by @​Zylphrex

• Profiling: Better gevent support (#1822) by @​Zylphrex

• Profiling: Add profile context to transaction (#1860) by @​Zylphrex

• Profiling: Use co_qualname in python 3.11 (#1831) by @​Zylphrex

• OpenTelemetry: fix Use dict for sentry-trace context instead of tuple (#1847) by @​AbhiPrasad

• OpenTelemetry: fix extra dependency (#1825) by @​bernardotorres

• OpenTelemetry: fix NoOpSpan updates scope (#1834) by @​Zylphrex

• OpenTelemetry: Make sure to noop when there is no DSN (#1852) by @​antonpirker

• FastAPI: Fix middleware being patched multiple times (#1841) by @​JohnnyDeuss

• Starlette: Avoid import of pkg_resource with Starlette integration (#1836) by @​mgu

• Removed code coverage target (#1862) by @​antonpirker

1.13.0

Various fixes & improvements

• Add Starlite integration (#1748) by @​gazorby

  Adding support for the Starlite framework. Unhandled errors are captured. Performance spans for Starlite middleware are also captured. Thanks @​gazorby for the great work!

  Usage:

  from starlite import Starlite, get

... (truncated)

Commits

• 8c4a19a Updated changelog
• f095df7 release: 1.14.0
• d27808f Removed code coverage target (#1862)
• cd2f51b feat(profiling): Add profile context to transaction (#1860)
• d515233 Always remove Django session related cookies. (#1842)
• 032ea57 Make sure to noop when there is no DSN (#1852)
• 086e385 feat(profiling): Use co_qualname in python 3.11 (#1831)
• 0714d9f Fix middleware being patched multiple times when using FastAPI (#1841)
• 1ac27c8 fix(opentelemetry): Use dict for sentry-trace context instead of tuple (#1847)
• 504188c fix extra dependency (#1825)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (6b6d152) 67.59% compared to head (ecb9fa9) 67.59%.

Additional details and impacted files

@@             Coverage Diff              @@
##           development     #296   +/-   ##
============================================
  Coverage        67.59%   67.59%           
============================================
  Files               31       31           
  Lines             4154     4154           
============================================
  Hits              2808     2808           
  Misses            1346     1346           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jlchang]

@eweitz if the build passes, what else is necessary before merging this PR? sentry-sdk is used in monitor.py but I don't know if we have any tests that explicitly check for Sentry reporting in this repo.

If we approve this PR, do we need to test in staging to ensure that an expected ingest failure mode gets reported in non-prod Sentry?

[eweitz]

If we approve this PR, do we need to test in staging to ensure that an expected ingest failure mode gets reported in non-prod Sentry?

We could, but I don't think we need to. The worst case I can reasonably envision from deferring such a check is that Ingest Pipeline stops logging unhandled errors to Sentry. I see no errors logged from Ingest to Sentry in the last 90 days. And IIUC, we also log unhandled errors in delocalized GCS files and Rails local logs, and log handled errors / user validation errors in Mixpanel, so the segment of unlogged errors seems like it would be small (if anything) in that worst case. That worst case strikes me as unlikely; breaking changes in 1.0.0 don't seem likely to affect our usage.

Given that, while addressing within 30 days this security issue marked as high severity is important for security compliance, specific manual regression testing here seems less essential.

Reading the security report indicates the issue requires multiple conditions that aren't used in this project. So while merging and deploying this update seems like it'd be fine, it seems unlikely we'd ever meet the conditions for this issue to manifest -- e.g. we're prohibited from setting sendDefaultPII set to True for pre-existing reasons.

[jlchang]

@eweitz Thanks for walking me through how to evaluate a security update PR. It's completely obvious, in retrospect, that this PR can be evaluated in the context of 1. what breaking changes are involved in the update and 2. what the security report is concerned about.

I really appreciate the link to the Sentry report showing that we no longer get logger:ingest-pipeline errors - I'll make a note to investigate as the mixpanel data suggests those error still occur. At least we won't attribute those errors to this update!