meta(changelog): Update Changelog for 7.57.0 #8417
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[Gitflow] Merge master into develop
In our (still internal) `trace` function, we don't yet check if `hasTracingEnabled` returns `true` before trying to start a span or a transaction. This leads to the following problematic UX path that was discovered [here](#5838 (reply in thread)): 1. Users don't set `tracesSampleRate` (or `tracesSampler`), causing some SDKs (NextJS, SvelteKit) to **not** add the `BrowserTracing` integration, which in turn means that tracing extension methods are not added/registered. 2. Users or, more likely, other parts of our SDK (e.g. SvelteKit's wrappers/handlers) call `trace` which will still try to start a span/txn. 3. Users will get a console warning that tracing extension methods were not installed and they should manually call `addExtensionMethods` which is completely misleading in this case. This fix makes `trace` check for `hasTracingEnabled()` in which case it will not start a span but just invoke the error callback if an error occurred.
#8369) Previously, in our Angular routing instrumentation, we only stopped routing spans when a navigation ended successfully. This was because we only listened to [`NavigationEnd`](https://angular.io/api/router/NavigationEnd) router events. However, the Angular router emits other events in unsuccessful routing attempts: * a routing error (e.g. unknown route) emits [`NavigationError`](https://angular.io/api/router/NavigationCancel) * a cancelled navigation (e.g. due to a route guard that rejected/returned false) emits [`NavigationCancel`](https://angular.io/api/router/NavigationCancel) This fix adjusts our instrumentation to also listen to these events and to stop the span accordingly.
The `TryCatch` default integration interferes with the `SentryErrorHander` error handler of the Angular(-Ivy) SDKs by catching certain errors too early, before the Angular SDK-specific error handler can catch them. This caused missing data on the event in some or duplicated errors in other cases. This fix filters out the `TryCatch` by default, as long as users didn't set `defaultIntegrations` in their SDK init. Therefore, it makes the previously provided [workaround](#5417 (comment)) obsolete.
Since @sentry/sveltekit depends on @sentry/vite-plugin, which in turn depens on `@sentry/node@^7.19.0` & `@sentry/tracing@^7.19.0`, this fails to install in E2E tests for pre-release versions (e.g. `7.57.0-beta.0`), as the prerelease does not satisfy the range `^7.19.0`. So we override this to `*` to ensure this works as expected.
This field was added as part of v7.56.0, but `SlowClickFrameData` was created before that. Having `clickCount` be required breaks backwards compatibility, it should be optional.
…tions` from SDK (#8382) When refactoring our `@sentry/tracing` package and exporting tracing related integrations from SDK packages, we apparently forgot to export `autoDiscoverNodePerformanceMonitoringIntegrations` from the Serverless SDK. This fix re-adds the export.
It seems in some environments `sessionStorage` my be unset to `null` or similar. To be extra careful, we can guard for existence as well there. Fixes #8392
This PR adjusts the exception name generation for non-error objects in the browser SDK. ref #7941
Add https://eslint.org/docs/latest/rules/no-return-await to eslint config to remove usage of uneeded async/await calls. This helps reduce microtasks being generated, which can help reduce memory pressure caused by the SDK. The downside of removing `return await` is that stacktraces get slightly worse for async errors that use these methods, as we no longer pause execution on return for the engine to grab context on, but instead just pass through the promise, but I think it's worth it for this to be the default, and for us to opt-in to the better stacktraces if need be.
When running `yarn build:watch` I found some circular deps: ``` src/eventBuffer/index.ts -> src/eventBuffer/EventBufferArray.ts -> src/eventBuffer/index.ts src/eventBuffer/index.ts -> src/eventBuffer/EventBufferProxy.ts -> src/eventBuffer/EventBufferCompressionWorker.ts -> src/eventBuffer/index.ts ``` This refactors the `EventBufferSizeExceededError` export to remove that.
…mentation (#8391) As outlined in #8174 (comment), our current SvelteKit fetch instrumentation breaks SvelteKit's request caching mechanism. This is problematic as `fetch` requests from universal `load` functions were made again on the client side during hydration although the response was already cached from the initial server-side request. The reason for the cache miss is that in the instrumentation we add our tracing headers to the requests, which lead to a different cache key than the one produced on the server side. This fix vendors in code from [the SvelteKit repo](https://github.com/sveltejs/kit) so that we can perform the same cache lookup in our instrumentation. If the lookup was successful (--> cache hit), we won't attach any headers or create breadcrumbs to 1. let Kit's fetch return the cached response and 2. not add spans for a fetch request that didn't even happen.
This change ensures that browser profiles are sent in the same envelope as transactions and enables sourcemap support.
Added an integration test application using [Remix 1.17.0](https://github.com/remix-run/remix/releases/tag/remix%401.17.0) and [v2 future flags](https://remix.run/docs/en/main/pages/api-development-strategy) to see the state of current SDK support for v2.
ref #8352 As we work toward adding tracing without performance support, this PR updates the `BrowserTracing` integration to use and favour the top level `tracePropagationTargets` option if it exists. This option was made top level in #8395 `tracePropagationTargets` is now part of the unified API for distributed tracing. It's also expected that electron/react native will behave the same way as well. This also leaves us the flexibility to extract tracing out of BrowserTracing, or create a new integration that just does tracing but no performance monitoring. We can make sure this migration is smooth and easy to understand with a good set of docs, which is what I will be working on next. In these docs changes, we'll be updating the automatic instrumentation sections, and formally documented `tracePropagationTargets` as a high level option.
Collect span information on how long the async calls to profiler.stop take which will help us evaluate if calling txn.finish after profiler.stop is a viable approach
This adds an experiment that will allow http timings to be captured. We currently capture timings on Sentry SaaS with some custom code and append them to the spans, which has been helpful to identify some performance problems that were previously hidden (http/1.1 stall time). Following this work we can add these to the waterfall to represent measurements as subtimings and will power an upcoming http/1.1 stall performance issue.
This updates the TS version we use from 3.8.3 to 4.9.5. This allows us to use newer TS features, as well as as improves compatibility with newer @types/xxx packages that use newer features, which leads to issues when transitive dependencies are used etc. We use [downlevel-dts](https://www.npmjs.com/package/downlevel-dts) to generate a 3.8 compatible types output _in addition_, so this should be fully backwards compatible. TS provides a built-in way to tell it to use a certain types output for a certain version, so this should work with no breaking change. The main changes necessary here are small tweaks to types which are required in 4.9.x.
lforst
approved these changes
Jun 28, 2023
CHANGELOG.md
Outdated
Comment on lines
15
to
16
| This means that this change should be fully backwards compatible and not have any noticable user impact, | ||
| but it opens the door to us using newer TypeScript features in the codebase going forward. |
There was a problem hiding this comment.
Maybe let's leave out the part where we say this opens doors and instead say something like "if you still encounter issues please let us know".
size-limit report 📦
|
AbhiPrasad
approved these changes
Jun 28, 2023
mydea
force-pushed
the
prepare-release/7.57.0
branch
from
02566b2
to
4d87498
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updates the changelog for 7.57.0