-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
meta(changelog): Update changelog for 8.25.0 #13284
Merged
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
The bundler-plugins still refer to the option as `excludePerformanceMonitoring` ([here](https://github.com/getsentry/sentry-javascript-bundler-plugins/blob/main/packages/bundler-plugin-core/src/types.ts#L260)), but this is going to be renamed to `excludeTracing`, so I already used the new naming as discussed with @Lms24 and @mydea. closes #13013
[Gitflow] Merge master into develop
Export function `getTraceMetaTags` that gives users an easy way to get stringified Html meta tags for server->client trace propagation. --------- Co-authored-by: Andrei <168741329+andreiborza@users.noreply.github.com>
ref #13210 1. Update sdk list and issue labeling workflow to be up-to-date. 2. Instead of attaching labels, categorize issues with issue types.
As per https://vitest.dev/config/#globals > By default, vitest does not provide global APIs for explicitness I think we should follow vitest defaults here and explicitly import in the APIs that we need. This refactors our Nestjs SDK tests to do so. ref #11084
#13250) The bundler-plugins still refer to the option as `excludePerformanceMonitoring` ([here](https://github.com/getsentry/sentry-javascript-bundler-plugins/blob/main/packages/bundler-plugin-core/src/types.ts#L260)), but this is going to be renamed to `excludeTracing`, so I already used the new naming as discussed with @Lms24 and @mydea. part of #13013
Discovered today that TS 3.8 doesn't understand `// @ts-expect-error`. Since we test on Node 22 also with TS 3.8, we shouldn't use `ts-expect-error` in test files as TS 3.8 would simply ignore the comment and throw a type error. Instead, it's fine to use `@ts-ignore` in these test files.
… undefined` (#13261) If users or our higher-level SDKs pass `defaultIntegrations: undefined` to the Browser SDK's init options, it deactivates all default integrations. As per our docs, this should only happen if you explicitly pass `defaultIntegrations: false`. This PR fixes this by removing the `defaultIntegrations` key from the user options object before merging the options together. --------- Co-authored-by: Francesco Novy <francesco.novy@sentry.io>
…13230) Adds automatic instrumentation of exception filters to `@sentry/nestjs`. Exception filters in nest have a `@Catch` decorator and implement a `catch` function. So we can use that to attach an instrumentation proxy.
--------- Co-authored-by: Charly Gomez <charly.gomez@sentry.io>
… over `event` (#13266) Currently, the AWS otel integration (and our `wrapHandler` fallback) try to extract sentry trace data from the `event` object passed to a Lambda call. The aws-sdk integration, however, places tracing data onto `context.clientContext.Custom`. This PR adds a custom `eventContextExtractor` that attempts extracting sentry trace data from the `context`, with a fallback to `event` to enable distributed tracing among Lambda invocations. Traces are now connected. Here an example: `Lambda-A` calling `Lambda-B`: ``` import { LambdaClient, InvokeCommand } from "@aws-sdk/client-lambda"; import * as Sentry from "@sentry/aws-serverless"; export const handler = Sentry.wrapHandler(async (event, context) => { const client = new LambdaClient(); const command = new InvokeCommand({ FunctionName: `Lambda-B`, InvocationType: "RequestResponse", Payload: new Uint16Array(), }) return client.send(command); }); ``` `Lambda-B`: ``` import * as Sentry from "@sentry/aws-serverless"; Sentry.addIntegration(Sentry.postgresIntegration()) export const handler = Sentry.wrapHandler(async (event) => { const queryString = "select count(*) from myTable;"; return await Sentry.startSpan({ name: queryString, op: "db.sql.execute" }, async (span) => { console.log('executing query', queryString); }) }) ``` ![CleanShot 2024-08-07 at 16 34 51@2x](https://github.com/user-attachments/assets/43f5dd9e-e5af-4667-9551-05fac90f03a6) Closes: #13146
…13248) This introduces a new option for the `graphqlIntegration`, `useOperationNameForRootSpan`, which is by default `true` but can be disabled in integration settings like this: `Sentry.graphqlIntegration({ useOperationNameForRootSpan: true })`. With this setting enabled, the graphql instrumentation will update the `http.server` root span it is in (if there is one) will be appended to the span name. So instead of having all root spans be `POST /graphql`, the names will now be e.g. `POST /graphql (query MyQuery)`. If there are multiple operations in a single http request, they will be appended like `POST /graphql (query Query1, query Query2)`, up to a limit of 5, at which point they will be appended as `+2` or similar. Closes #13238
This PR does three things: 1. It ensures we infer the IP (in RequestData integration) from IP-related headers, if available. 2. It ensures we do not send these headers if IP capturing is not enabled (which is the default) 3. It removes the custom handling we had for this in remix, as this should now just be handled generally Closes #13260
This PR streamlines our browser integration tests a bit more: 1. We now only install chromium for playwright tests in most places. This may help cut down test run time a bit, as we do not need to install native dependencies for webkit and firefox everywhere. 2. I changed how we split the matrix jobs for the browser integration tests. Previously, we sharded this via playwright. Now, we only do this for esm tests, which we now only run in chromium, not all browsers. Only the full bundle tests are run in all browsers (they are considerably faster than the esm tests...), and there we now do not use sharding, but have one matrix job for chromium (default), one for webkit and one for firefox (where each can only install the native dependencies it needs). 3. I renamed the jobs a bit so that we can see a bit more of the job name in the Github UI... it still truncates but you see more than before, at least... 4. For all other playwright tests (e.g. e2e tests etc) we only install chromium, AFAIK we do not have any non-chromium tests anywhere there. Some data points: * E2E tests seem to be about 10-20% faster than before, by looking through traces here: https://sentry.sentry.io/performance/trace/c5c1c643f1db0e8dd97df658405c2035/?field=title&field=event.type&field=project&field=user.display&field=timestamp&name=All+Events&node=txn-8892bc908791478aba163dd3edd373b4&project=5899451&query=&sort=-timestamp&source=discover&statsPeriod=1h×tamp=1723118364&yAxis=count%28%29 * For the playwright steps it's a bit harder to say as they are renamed, also they are not super consistent in execution time, we'll have to monitor it a bit afterwards, but subjectively it appears a bit shorter in most cases too.
Add a wrapper for SvelteKit server routes. The reason is that some errors (e.g. sveltekit `error()` calls) are not caught within server (API) routes, as reported in #13224 because in contrast to `load` function we don't directly try/catch the function invokation. For now, users will have to add this wrapper manually. At a later time we can think about auto instrumentation, similarly to `load` functions but for now this will remain manual.
andreiborza
requested review from
mydea,
lforst,
Lms24,
AbhiPrasad,
chargome,
s1gr1d and
nicohrubec
August 8, 2024 16:53
chargome
approved these changes
Aug 9, 2024
6 tasks
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.