meta(changelog): Update changelog for 7.89.0 #9915
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
See: https://github.com/codecov/vscode/pull/35/files#diff-084bdbbae104c91c8af1a0b632b46b9e797366d5427a2f11aa0332007866af39R2334-R2359 This is undocumented and in alpha, but I figured we should try testing it out!
…ope()` (#9846) In preparation for #9841, as we want to deprecate `configureScope`, refactor our own usage of this away. I used a new transformer of sentry-migr8 for this, which did most of the heavy lifting. I only needed to fix the block usage (which is more a stylistic issue than an actual problem). In some follow up, I'll also create a migr8 transform to refactor hub usage away, to e.g. refactor `getCurrentHub().getScope()` to `getCurrentScope()` etc. But for now this is OK I think.
As that is browser only. Closes #9860
Except for places where we are really passing a `hub` in, not using `getCurrentHub()`.
… `getCurrentHub` (#9868) Instead we can pass a client directly, and I refactored the method to avoid setting extra on the scope, and just set it on the event directly - as this is also kind of leaking right now, because the extra may also be applied to other events using the same scope.
This refactors Node integrations to use `processEvent`. Missing is the LocalVariables integration, as that is more complicated and may need to be refactored in a different way to properly work.
…9251) Here is my proposal to fix `getRandomByte` function throwing an error due to `crypto.getRandomValues` returning `undefined` in old browser engines like Chromium 23. This error could be fixed as well by using a polyfill in every project that imports and uses Sentry but, since the change of this PR only involved keeping the `Uint8Array` reference in a variable, I thought it would be worth it to give it a try.
Step by step, eradicating the hub... Note: I haven't found a way to mark an attribute type of a function as deprecated 😬 I think it's OK here, but generally a bit annoying/tricky...
To align this with OpenTelemetry and make some things possible that are currently not easily doable without `pushScope` / `popScope`. Noticed this because currently it's not easily possible to e.g. use `withScope` in places like [this](#9862 (comment)). This should be backwards compatible because any code that previously relied on this returning `void` should still work.
This PR adds new types for function-based integrations, that eventually
(in v8) should fully replace the class-based functions.
This also introduces a small helper function to make writing such
integrations easier (as we need to set an id/name etc. on the
integration). With this, you can write an integration like this:
```ts
const inboundFiltersIntegration = makeIntegrationFn(
'InboundFilters',
(options: Partial<InboundFiltersOptions>) => {
return {
processEvent(event, _hint, client) {
const clientOptions = client.getOptions();
const mergedOptions = _mergeOptions(options, clientOptions);
return _shouldDropEvent(event, mergedOptions) ? null : event;
}
}
});
```
And you get a fully typed integration ready to go!
For backwards compatibility, and so that we can actually start
converting integrations in v7 already, this PR also adds a small utility
`convertIntegrationFnToClass()` to convert such an integration to the
"current" integration class syntax.
So we can actually already start porting integrations over like this:
```js
/** Inbound filters configurable by the user */
// eslint-disable-next-line deprecation/deprecation
export const InboundFilters = convertIntegrationFnToClass(inboundFiltersIntegration);
```
Then, in v8 we only have to remove all the `convertIntegrationFnToClass`
calls, export the integration functions directly, and update the overall
integration types which can be passed to `init()` etc.
Resolves: #9344 Adds a new node integration for Hapi framework. Also exports a Hapi plugin to capture errors when the tracing instrumentation from `node-experimental` is used. Can be used with `node-experimental` ([Sample Error Event](https://sentry-sdks.sentry.io/issues/4624554372/?project=4506162118983680&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=1h&stream_index=0)) like: ```typescript const Sentry = require('@sentry/node-experimental'); Sentry.init({ dsn: '__DSN__', tracesSampleRate: 1.0, }); const Hapi = require('@hapi/hapi'); const init = async () => { const server = Hapi.server({ port: 3000, host: 'localhost' }); await server.register(Sentry.hapiErrorPlugin) server.route({ method: 'GET', path: '/', handler: (request, h) => { throw new Error('My Hapi Sentry error!'); } }); await server.start(); }; ``` Also can be used from `@sentry/node` with tracing ([Errored Transaction](https://sentry-sdks.sentry.io/performance/node-hapi:8a633340fc724472bb44aae4c7572827/?project=4506162118983680&query=&referrer=performance-transaction-summary&statsPeriod=1h&transaction=%2F&unselectedSeries=p100%28%29&unselectedSeries=avg%28%29), [Successful Transaction](https://sentry-sdks.sentry.io/performance/node-hapi:deeb79f0c6bf41c68c776833c4629e6e/?project=4506162118983680&query=&referrer=performance-transaction-summary&statsPeriod=1h&transaction=%2F&unselectedSeries=p100%28%29&unselectedSeries=avg%28%29)) and error tracking ([Event](https://sentry-sdks.sentry.io/issues/4626919129/?project=4506162118983680&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=1h&stream_index=0)) like: ```typescript 'use strict'; const Sentry = require('@sentry/node'); const Hapi = require('@hapi/hapi'); const init = async () => { const server = Hapi.server({ port: 3000, host: 'localhost' }); Sentry.init({ dsn: '__DSN__', tracesSampleRate: 1.0, integrations: [ new Sentry.Integrations.Hapi({server}), ], debug: true, }); server.route({ method: 'GET', path: '/', handler: (request, h) => { return 'Hello World!'; } }); await server.start(); }; ```
Instead of using `hub.addBreadcrumb()`.
Damn, merged a PR without rebasing it first, it did not have the new biome rules yet 😅 so develop is failing linting right now...
Instead, users should directly access the current scope via `getCurrentScope()`.
This PR adds support for `Deno.CronSchedule`. Since the `CronSchedule` type cannot be fully expressed by the Sentry `IntervalSchedule`, I instead copied the Deno code to convert to `CrontabSchedule`. I also added `checkinMargin: 1` since the Deno docs state that on Deno Deploy, crons can be up to 1 minute late.
Defaults to `webp` instead of `png`. This will also allow `quality` to work. Closes getsentry/team-replay#326
This PR introduces the new scope APIs to node-experimental. * `getCurrentHub()` is still around, but just a mock hub that uses other methods under the hood. * Instead, there are the following new APIs: * `getCurrentScope()` * `getIsolationScope()` * `getGlobalScope()` * `withIsolationScope()` Mostly existing tests should cover this OK. The main change here is that for spans, since we use the isolation scope any tags etc. added while the span is running are _also_ added to the resulting event. For POTEL, we automatically set an isolation scope whenever a http.server span is generated. Replaces #9419 --------- Co-authored-by: Luca Forstner <luca.forstner@sentry.io>
Setting the range to `1.x || 2.x` to include kit 2.0
Looks like Vite 5 module resolution for `@sentry/sveltekit` only works with defining conditional exports. Tested this locally with a Sverdle kit@1, kit@2 and the syntax website.
Skips capturing all responses < 500 that end up in `captureRemixServerException`.
adds a Sveltekit 2.0 E2E test application. Currently, we only test building. This shows that with #9872, our SDK works in SvelteKit 2.0. We should however add actual tests to both Kit 1.x and 2.x test apps.
Improve our logic to filter out "Not Found" errors in our server-side `handleError` hook wrapper: - We now use SvelteKit 2.0 - native [error properties](https://kit.svelte.dev/docs/migrating-to-sveltekit-2#improved-error-handling) (`status` ~and `message`~) to check for "Not Found" errors - Adjusted types for type safety and backwards compatibility with SvelteKit 1.x where the ~two properties~ property don't exist. - Updated Sveltekit to 2.0 in our dev dependency to work with latest types.
Looks like 404 errors weren't passed to the client side `handleError` hook in Kit 1.x but in 2.x they're now passed into the hook. This means, we need to filter them out.
mydea
reviewed
Dec 19, 2023
| @@ -4,6 +4,30 @@ | |||
|
|
|||
| - "You miss 100 percent of the chances you don't take. — Wayne Gretzky" — Michael Scott | |||
|
|
|||
| ## 7.89.0 | |||
There was a problem hiding this comment.
Let's call out the configureScope, pushScope and popScope deprecations maybe?
There was a problem hiding this comment.
I'd like to highlight Hapi as well in #9539
Lms24
approved these changes
Dec 19, 2023
CHANGELOG.md
Outdated
Comment on lines
7
to
13
| ## 7.89.0 | ||
|
|
||
| - chore(sveltekit): Add SvelteKit 2.0 to peer dependencies (#9861) |
There was a problem hiding this comment.
l: just feel like we could call this out
Suggested change
| ## 7.89.0 | |
| - chore(sveltekit): Add SvelteKit 2.0 to peer dependencies (#9861) | |
| ## 7.89.0 | |
| This release adds support for SvelteKit 2.0 in the `@sentry/sveltekit` package. If you're upgrading from SvelteKit 1.x to 2.x and already use the Sentry SvelteKit SDK, no changes apart from upgrading to this (or a newer) version are necessary. | |
| Furthermore, we've added a couple of deprecations for functions that will be removed in our upcoming v8 major release. | |
| - chore(sveltekit): Add SvelteKit 2.0 to peer dependencies (#9861) |
lforst
force-pushed
the
prepare-release/7.89.0
branch
2 times, most recently
from
18c7d17
to
9ca11fb
Compare
lforst
force-pushed
the
prepare-release/7.89.0
branch
from
9ca11fb
to
9f173e1
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.
No description provided.