-
Notifications
You must be signed in to change notification settings - Fork 56
Upgrade to Sentry 9.6.1 + Client side setup #654
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
base: development
Are you sure you want to change the base?
Conversation
New, updated, and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/@sentry/[email protected], npm/@sentry/[email protected] |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## development #654 +/- ##
===============================================
+ Coverage 54.71% 54.95% +0.24%
===============================================
Files 227 227
Lines 5253 5259 +6
Branches 812 812
===============================================
+ Hits 2874 2890 +16
+ Misses 2139 2128 -11
- Partials 240 241 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
bcf535c
to
8fc75e1
Compare
@kanej ready for review |
Removed deprecated packages:
sentry/tracing
andsentry/types
Updated sentry/node to latest version, 9.6.1
Added sentry/core, which is a transient dependency of sentry/node since some functions and types are not re-exported by sentry/node
Some concepts ceased to exist, for instance Transactions. So I migrated to the new approach which is to use only spans (top level spans are what transactions used to be)
Some methods e.g.
setTag
now should be invoked directly from Sentry, so our application is a bit more coupled to sentry instead of the abstract Telemetry class. I think it's unnecesary to have such abstraction, and would get rid of it. If we wanted to completely decouple from Sentry it'd be too much overhead for little benefitNew custom client side setup to avoid global extension host context
Global uncaughtError + unhandledRejection handlers on client process, with a filter on stack traces
Capture and report as handled errors on every execution path on the client side
Since we have to manually call
captureException
on unhandled errors, they are not marked as "unhandled" by sentry, so I added an additional tagisHandled
, for client side events