meta: Update CHANGELOG for 7.67.0 #8941
Merged
Conversation
This file contains hidden or 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
This renames & restructures the type exports from `@sentry/replay`. We want to deprecate the `@sentry/replay` package eventually - users should import everything they need directly from e.g. `@sentry/browser` or `@sentry/react`. ref #8864
This tries to simplify the logger to avoid the global lookup. If you have more than one utils, having multiple loggers would be the least of your problems.
[Gitflow] Merge master into develop
…ipt (#8814) Updated `sentry-upload-sourcemaps` script: - Updated `sentry-cli` to: `2.20.4` - Added a script to Inject debugids invoking `sentry-cli` (as this feature is not available in JS SDK of `sentry-cli` yet) - Added a script to delete sourcemaps after uploading them to Sentry. (default is to delete, created a new flag to prevent deletion)
…ns` (#8921) Add missing replay and profiling options to the `BrowserClientOptions` interface. Previously, we only exposed these types to `BrowserOptions`. This led to type errors for users who directly create a client, without using `Sentry.init` (as reported in #8857). While one would think that `BrowserClientOptions` is basically a superset of `BrowserOptions` (leaving aside `stackparser`, `integrations` and `transport`) this is in fact not the case, which IMO is the core problem here. `BrowserClientOptions` only inherits the base `Options` (which are shared between browser and node), in addition to transport options. However, changing this so that, `BrowserClientOptions` inherits from `BrowserOptions` is a breaking change, so I opted to just add the missing options to `BrowserClientOptions`.
This defaults to 60min, and is capped at max. 60min (=you cannot specify a longer max duration than 60min). Closes #8758
Bumps [apollo-server-core](https://github.com/apollographql/apollo-server/tree/HEAD/packages/apollo-server-core) from 3.11.1 to 3.12.1. - [Release notes](https://github.com/apollographql/apollo-server/releases) - [Commits](https://github.com/apollographql/apollo-server/commits/apollo-server-core@3.12.1/packages/apollo-server-core) --- updated-dependencies: - dependency-name: apollo-server-core dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
…#8920) I noticed that we kind of extended the public API by exporting some things from opentelemetry-node that we need in node-experimental. I am deprecating these internals as I'm refactoring some things to be a bit cleaner IMHO. The one export we actually need outside I am exporting as `_INTERNAL_getSentrySpan` to make it clear this is not meant to be used otherwise. The main reason I am not just exporting this is that this _may_ have to change if we change how we internally store/handle spans - e.g. if we move away from the map this is just not possible to have anymore, and I do not want to lock us into having to support this in the future.
1. Make sure it works consistently when not calling `connection.connect()` (which is optional) - it used to only register the mysql config on the second call, as it calls `connect` under the hood but only after we already tried to fetch it again. 2. Make sure it works without a callback.
This re-implements the new performance APIs: * `startActiveSpan` * `startSpan` * `getActiveSpan` In `@sentry/node-experimental`, where these delegate to OTEL under the hood. I tried to make sure to have _exactly_ the same APIs as we have for these functions without this. There are some caveats with this: * calling `span.finish()` may behave in unexpected ways - it is not supported to manually finish a span. * Calling `scope.getSpan()` will not work * Calling `span.startSpan()` will not work Basically, only the top level exported methods work, nothing else.
…8797) This PR implements a strategy to sync the OpenTelemetry Context with our own Hub forking for AsyncContext. This works by fully relying on OpenTelemetry to handle async context isolation/forking. 1. We implement a custom OTEL ContextManager that wraps the default AsyncHooks manager, but makes sure to also fork the hub for each context change & puts the hub on the OTEL context so we can retrieve it. 2. Then, we also have a custom Sentry AsyncContextStrategy which just refers to OTEL context and picks the hub from there we put there in 1. This means we do not need to do any context forking ourselves anymore, so no need for e.g. `Sentry.Handlers.requestHandler()` and stuff like this. It _should_ also mean that Sentry & OTEL should be as in sync as possible. Some notes: * Currently only works for AsyncHooks, which should be fine I guess. Could also be exteded to work with other implementations as well.
Cleaning up a leftover from v6 when we still built Vue CDN bundles.
Report exceptions caught by our Vue error handler and routing instrumentation as unhandled. Detailed write up in #8890
Deprecate the `wrap` function exported from `@sentry/browser`. This function is documented nowhere, not part of the unified API and afaict not used by any SDKs depending on `@sentry/browser`.
) For more details see #8890
Lms24
force-pushed
the
prepare-release/7.67.0
branch
from
ee831d4 to
08a2f0f
Compare
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
There are cases when global objects such as the window object are shimmed that they define properties such as `document`, but the actual value is undefined. This exact situation has been occurring and is causing the instrumentDOM function to throw an error as `'document' in WINDOW` is technically true though the value is falsey. We should rather attempt an actual check of the value being truthy rather than if the property is defined Co-authored-by: Luca Forstner <luca.forstner@sentry.io>
Lms24
force-pushed
the
prepare-release/7.67.0
branch
from
08a2f0f to
09f7f7e
Compare
mydea
approved these changes
Sep 5, 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.
Draft for now, lmk if PRs should still be included in the release.