meta(changelog): Update changelog for 7.65.0 #8878
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
It _seems_ they do not do anything - at least I compared the complete build ouput for node, core & browser with & without this, and it appeared _exactly_ the same. Not sure, maybe I missed something, it is not entirely clear to me how/what/when these would be applied etc.
Bumps [protobufjs](https://github.com/protobufjs/protobuf.js) from 6.11.3 to 6.11.4. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/protobufjs/protobuf.js/commits">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> 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 show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@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](https://github.com/getsentry/sentry-javascript/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…erLoadWithSentry` (#8801) The SvelteKit SDK caused server load data to be invalidated, resulting in said functions being called on every route change. I initially thought this was related to our Kit-specific client fetch instrumentation which turned out not to be causing this. Instead, the culprit is our `wrapServerLoadWithSentry` wrapper: In the wrapper, we access `event.route.id` to determine the route of the load function for the span description. Internally, SvelteKit puts a proxy on certain `event` properties, such as `event.route`. In case any property of `event.route` was accessed, [SvelteKit marks this](https://github.com/sveltejs/kit/blob/e133aba479fa9ba0e7f9e71512f5f937f0247e2c/packages/kit/src/runtime/server/page/load_data.js#L111-L124) internally and send along a flag to the client. On a route change, the client would [check this flag](https://github.com/sveltejs/kit/blob/e133aba479fa9ba0e7f9e71512f5f937f0247e2c/packages/kit/src/runtime/client/client.js#L572) and mark the route as invalidated, thereby causing a [call to the load function](https://github.com/sveltejs/kit/blob/e133aba479fa9ba0e7f9e71512f5f937f0247e2c/packages/kit/src/runtime/client/client.js#L641) on each navigation. --------- Co-authored-by: Kamil Ogórek <[email protected]>
This should cut down on the `yarn install` step.
…fault instrumentation (#8802) Remove our custom SvelteKit client fetch instrumentation which we created when we initially worked on the SDK. Back then I didn't think that it's possible to use our default fetch instrumentation from `BrowserTracing`, due to timing issues where Kit would store away `window.fetch` (and use the stored version in `load` functions) before our SDK was initialized. After receiving some [hints](sveltejs/kit#9530 (comment)) how it might be possible, we now have a way to instrument `fetch` everywhere on the client (including the one in `load`) functions. This works in two parts: 1. During the initial page load request, our server-side `handle` wrapper injects a script into the returned HTML that wraps `window.fetch` and adds a proxy handler (`window._sentryFetchProxy`) that at this time just forwards the fetch call to the original fetch. After this script is evaluated by the browser, at some point, SvelteKit loads its initial client-side bundle that stores away `window.fetch`. Kit also patches `window.fetch` itself at this time. Sometime later, the code from the `hooks.client.js` file is evaluated in the browser, including our `Sentry.init` call: 2. During `Sentry.init` we now swap `window.fetch` with `window._sentryFetchProxy` which will make our `BrowserTracing` integration patch our proxy with our default fetch instrumentation. After the init, we swap the two fetches back and we're done.
Force a flush after each click, otherwise its possible that we have a flush inbetween the 3 clicks.
Fixes a bug where we incorrectly returned from the sveltekit fetch proxy Html script.
We've been using `_loadAndCheckSession` both in initial session setup as well as when checking for expiration of session. This leads to some not-so-optimized stuff, as we kind of have to do double duty in there (e.g. we constantly re-assign the session etc). This streamlines this by splitting this into: * `_initializeSessionForSampling()`: Only called in `initializeSampling()` * `_checkSession()`: Called everywhere else, assumes we have a session setup yet Only the former actually looks into sessionStorage, the latter can assume we always have a session already. This also extends the behavior so that if we fetch a `buffer` session from storage and segment_id > 0, we start the session in `session` mode. Without this, we could theoretically run into endless sessions if the user keeps refreshing and keeps having errors, leading to continuous switchovers from buffer>session mode.
This site is dead, lets remove the image loading from it. --------- Co-authored-by: Francesco Novy <[email protected]>
Angular `build:transpile` actually depends on types, so we need to reflect that - otherwise, `yarn build:dev` fails if no types are built yet.
This removes a type cast for the performance observer and actually adds some guards to make sure we do not run into cases where a property we expect to exist does not exist. It seems we sometimes ran into cases where `nextHopProtocol` would be `undefined`, not a string, leading to https://github.com/getsentry/sentry-javascript/blob/develop/packages/tracing-internal/src/browser/request.ts#L202 failing. I now specifically check for the existence of this property, as well as also adding a default for all the time based stuff (0) to ensure these also work in the case one of the fields does not exist (instead of checking for existence of all of them). Closes #8870 Closes #8863
size-limit report 📦
|
In our `OnUncaughtException` integration, we have to emulate Node's default behaviour of logging errors to the console. For some reason though, we only logged the stack trace of an `error` with a stack trace instead of the entire error object. As reported in #8856, this causes additional properties on the error (such as `cause`) not to be logged anymore which doesn't reflect Node's default behaviour (see issue for comparison). This patch simplifies the `console.error` call to just always log the entire `error`.
…rTracing` (#8874) This PR deprecates `BrowserTracing`'s `tracePropagationTargets` option in favour of the top-level Sentry.init option. When introducing Tracing without Performance, we opted to [promote `tracePropagationTargets` to a top-level option](#8395). We deprecated the integration-level option in Node's `Http` integration but not in `BrowserTracing`. This patch fixes that.
lforst
force-pushed
the
prepare-release/7.65.0
branch
from
9200f86 to
31979c6
Compare
Lms24
approved these changes
Aug 28, 2023
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.
No description provided.