meta: Update CHANGELOG for 7.45.0 #7599
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
…uests (#7553) We noticed that sometimes request would remain in a seemingly pending state. After some investigation, we found out that the limit of 64kb for keepalive-enabled fetch requests is not per request but for all parallel requests running at the same time. This fixes this by keeping track of how large the pending body sizes are, plus the # of pending requests, and setting keepalive accordingly.
```js
const fetchResult = Sentry.trace({ name: 'GET /users'}, () => fetch('/users'), handleError);
```
Add routing instrumentation to the client SvelteKit SDK. Pageload navigations are created on function call as always and updated with a proper name once the `page` store emits the route id. Navigation transactions are created by subscribing to the `navigating` store. No need for user configuration, as the instrumentation will be added automatically on SDK intialization.
…hSentry` (#7567) Our E2E tests were [failing](https://github.com/getsentry/sentry-javascript/actions/runs/4488942749/jobs/7894376591#step:6:6185) because apparently we don't initialize a client while building a NextJS app. This caused the tracing extension methods to not be added, resulting in `startTransaction` returning `undefined`. Not sure if this is the best way to fix this but it seems to work (h/t @timfish for the fix).
If `error.cause` is already defined, attempt to walk down the error chain to set the `ReactErrorBoundary` error.
We now run all tests into a single spawned process, which should hopefully speed this up a bit. We also reduce the # of repetitions from 100 to 50 to ensure we do not run overtime.
--------- Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
We discovered that our serverside `handleLoadWithSentry` wrapper caused two distinct transactions being created on page loads - one for the page load request and one for the `load` function (if one exists for that page). This shouldn't happen. We need to investigate how to fix this. As a short-term solution, we disable tracing on the serverside load wrapper to avoid quota usage increase for our users.
…tly (#7584) Previously our Kit routing instrumentation used the parameterized route id to determine if the origin and destination of the navigation were identical (in which case we don't want to create a navigation transaction). This caused navigations from e.g. `/users/123` to `users/456` to not create a transaction because their route id was identical. This PR fixes this bug by using the raw URL which we also get from the `navigating` store emissions. Furthermore, this PR fixes the transaction source which previously was always set to `route`, even if no route id was available.
Previously, our server `wrapLoadWithSentry` wrapper assumed that `load` in `+page.ts` and `+page.server.ts` work identically. Unfortunately, the load `event` arg has different contents for both, namely that the server-only load event contains a `request` object while the shared (client and server) load event doesn't. This patch fixes that by distinguishing between the two load types within the wrapper. Users can still use the same wrapper for both cases. Furthermore, this patch removes the usage of domains in the load wrapper, as on the server-side, as we're already in a domain when `handleSentry` is used. Creating another domain here, caused the creation of a new transaction instead of adding the span to the transaction that was created by `handleSentry`.
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.
Here we go again...