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.

…ts (#13213)

Fixes #13184

We can now await here because we use `vitest`, so there should be no
jsdom problems :)

But really these tests should live in playwright instead.

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>

Closes: #12550

…13274)

ref: #13273

… 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&timestamp=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.