meta(changelog): Update changelog for v8.0.0-alpha.1 #10857
Closed
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
[Gitflow] Merge master into develop
We don't generate coverage report for these, so we should not try to upload them to codecov, as the action warns about this.
Fixes #10525 When writing the rollup config, we didn't include the debug build plugin. This led to things not be replaced properly as `profiling-node` bundles everything into a single file. This was also causing issues in our CI: https://github.com/getsentry/sentry-javascript/actions/runs/7804351046/job/21287026518?pr=10527 Backporting this fix to v7 so we can do a `7.100.1` release after we merge this in.
In CI currently on develop, we are stuck in a situation where we don't build bindings which means that the e2e tests always fail. Let's only run the profiling e2e tests whenever we change bindings, and make it a little more liberal for when we do run CI for changing bindings.
…10536) We are creating a replay breadcrumb when user feedback was submitted, however, the it was not typed correctly, which the timestamp not being included in the proper location.
As pointed out here, and I also did notice that myself, it is not super
nice - as you need to provide a generic integration to
`getIntegrationByName`, which is annoying to do in a type safe way, esp.
if you want to avoid deprecations:
```ts
const client = getClient();
const replay = client && client.getIntegrationByName && client.getIntegrationByName<ReturnType<typeof replayIntegration>>('Replay');
```
So IMHO a small utility `Sentry.getReplay()` is not unreasonable for
this 🤔
Co-authored-by: Luca Forstner <[email protected]>
Works toward #8844 in a more incremental way.
) This is an intermediate step to streamline what we need to customize in OTEL. This should make it easier to slowly remove customizations there. The main change is that you can set a `createHub` method on the main carrier, which will be used if set. This way, all the code we have to duplicate in node-experimental right now just to create the correct `OpenTelemetryHub` can mostly go away. We will remove this again during then v8 cycle.
closes #5665 Goodbye hub package, I've known you my whole (sentry) life. Moved tests into core where applicable, otherwise deleted tests that were redundant.
closes #5842 Also deletes `GlobalHandlers` integration deprecated export while I'm here.
Small removal for `spanStatusfromHttpCode`!
…mental (#10570) Co-authored-by: Luca Forstner <[email protected]>
Co-authored-by: Francesco Novy <[email protected]>
Add the Http 400 avoidance logic from our server-side `load` function instrumentation to the client-side wrapper. Didn't know that these errors were a thing on the client side but now that we know, we definitely don't want to capture them. Co-authored-by: Francesco Novy <[email protected]>
Add an `exports` field to the `package.json` for `@sentry/angular-ivy`. While it seems like regular Angular apps didn't need it, tools like `vitest` expect the field as soon as `type: "module"` is specified. --- Co-authored-by: Andrei Alecu <[email protected]>
Removes all references to `enableAnrDetection` and the `Anr` integration. Moves us toward #8844 in the node side.
After the deprecation in v7 we now remove `lastEventId`.
Removes `configureScope`, deprecated in #9887
…fined` (#10821) We previously didn't record local local variables with falsy values because we checked for truthiness instead of definedness when unrolling and serializing the variable values. This PR changes how we check for and extract variable properties to record - falsy values (`0`, `''`, `false`) - `null` - `undefined` --------- Co-authored-by: Luca Forstner <[email protected]>
Move relevant integrations. Part of #9833
This PR fixes a few things about the OTEL handling of our SDK. 1. Ensure that attributes are actually correctly put on the trace data - we used to remove e.g. `sentry.sample_rate` which we don't do in "main" SDK. Question: Should we remove the `otel.attributes` context data then? As this is kind of redundant at this point with the `data` on the trace? 2. Ensure we put the `transaction` tag correctly on the transaction, to align with "main" SDK. 3. Ensure we store the incoming DSC as traceState, so we can pick this up. This can include e.g. transaction name and stuff like this to persist.
…hr/captureRequestSize` (#10777) [maybe] fixes this flakey test
It seems this is failing (sometimes?) and I don't think we need it anymore. e.g. see https://github.com/getsentry/sentry-javascript/actions/runs/8067785899/job/22039493880?pr=10825
- add docstring and comments for all fields - make attachmentType type more specific
This implements `forceTransaction` for otel/node.
This PR removes the `ignoreTransactions` default values which were all patterns trying to identify health check transactions.
This is the version that has async local storage support, which is what we set as our minimum supported version.
…ns API (#10813) This PR updates `@sentry/vite-plugin` used in the SvelteKit SDK from version 0.6.x to the latest 2.x version. In line with this change, we now also decoupled the public API of the vite plugin from the SvelteKit SDK public API, meaning we can bump to a higher plugin major version while we stay in the same SDK major version. Concrete changes: - We now use DebugId-based sourcemap upload 🎉 - Due to architecture changes in `@sentry/vite-plugin`, our `sentrySvelteKit` plugin factory function returns 6 (5x sourcemap, 1x auto instrumentation) plugins instead of previously two. This is because the Vite plugin now consists of several individual plugins. - We still have to modify source maps a bit before uploading them and all of this should still happen as late as possible. So we still create a customized version of the uploading plugin and return that instead of the original one. - Also added direct usage of `MagicString` to inject global values needed during runtime. Previously, I just handed my modified code to the original plugin's `transform` hook which might have even messed up source maps. - The new API is a subset of all Sentry Vite plugin options. - I'm happy to add more options before merging this PR. I just don't think we need all of them right from the start. As an alternative, we could allow users to pass in arbitrary options and we type them as `unknown` or something along these lines 🤔 Example usage (showing all available options; all are optional) ```js sentrySvelteKit({ autoUploadSourceMaps: true, sourceMapsUploadOptions: { org: process.env.SENTRY_ORG, project: process.env.SENTRY_PROJECT, authToken: process.env.SENTRY_AUTH_TOKEN, release: { name: '1.0.1', inject: true }, sourcemaps: { assets: ['./build/*/**/*'], ignore: ['**/build/client/**/*'], filesToDeleteAfterUpload: ['./build/**/*.map'] } }, autoInstrument: true, debug: true }), ``` closes #9835 closes #8283 --------- Co-authored-by: Francesco Novy <[email protected]>
Also stop clearing out sentry attributes, we don't actually want that (except for the parent sampled stuff for now).
For whatever reason, builds are weirdly failing now on CI, most probably due to caching issues etc... let's see if this can fix this, possibly...
We want to hard-pin bundler plugin versions in the SDKs to avoid telling users to upgrade (or downgrade) a dependency of our SDK. Instead, we'll just bump the version within the SDK if there's a concrete reason to do so.
This also resolves the circular dependencies we have in core right now by moving utils around a bit.
This reverts commit a2b7e3c.
Turns out you cannout use `{xx,yy}` glob syntax for cache outputs, which
broke everything. oops....
- test we forgot to delete fully - comments that don't apply anymore
This is done to ensure all tests still pass when we bump the version, as versions in bundler plugins need to be overwritten for e2e tests etc.
…ta (#10840) This removes usage of deprecated options to `startSpan`, and removes the `trackHeaders` option to the astro middleware in favor of using the general request data integration that should pick this up if put on the scope as SDK processing metadata.
mydea
force-pushed
the
prepare-release/v8.0.0-alpha.1
branch
from
de6f45d to
34e8ead
Compare
mydea
force-pushed
the
prepare-release/v8.0.0-alpha.1
branch
from
34e8ead to
01da347
Compare
|
Oops, typo - see #10858 |
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.
First v8 release incoming!