`GoogleGenerativeAI` could be mistaken for a different SDK, and the
package name is also incorrect. It’s best to refer to this as the Google
Gen AI SDK, as described in the official documentation:
https://cloud.google.com/vertex-ai/generative-ai/docs/sdks/overview
.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Updates CHANGELOG wording to use "Google Gen AI", rename
`GoogleGenerativeAI` to `GoogleGenAI`, and correct package from
`@google/generative-ai` to `@google/genai`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
872d223. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

...r Vercel AI gen spans (#17811)
This PR fixes a mismatch between ai.telemetry.functionId and
gen_ai.function_id. Function ids were ignored unless the span name
contained exactly one dot. This caused:
- gen_ai.function_id to be missing or inconsistent for valid generation
spans.
- Mismatch between ai.telemetry.functionId and gen_ai.function_id,
making trace exploration and metrics harder to interpret.
We now always respect experimental_telemetry.functionId when present,
where function id could be set as part of request.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Always update Vercel AI generate span names and set
`gen_ai.function_id` when `experimental_telemetry.functionId` is
present, removing the dot-count check.
> 
> - **Core (Vercel AI span processing)**:
> - In `packages/core/src/utils/vercel-ai/index.ts`
`processGenerateSpan`:
> - Remove `name.split('.')` dot-count check; always apply
`experimental_telemetry.functionId`.
> - When present, append function ID to the operation name and set
`gen_ai.function_id`.
> - Clarify comments on telemetry function ID usage.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
4b9fa48. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

[Gitflow] Merge master into develop

Not sure if this will also avoid these warnings from security alerts,
but it's worth a try.

This is a first step to de-compose the node/node-core `httpIntegration`
into multiple composable parts:
* `httpServerIntegration` - handles request isolation, sessions, trace
continuation, so core Sentry functionality
* `httpServerSpansIntegration` - emits `http.server` spans for incoming
requests
The `httpIntegration` sets these up under the hood, and for now it is
not really recommended for users to use these stand-alone (though it is
possible if users opt-out of the `httpIntegration`). The reason is to
remain backwards compatible with users using/customizing the
`httpIntegration`. We can revisit this in a later major.
These new integrations have a much slimmer API surface, and also allows
us to avoid having to prefix all the options etc. with what they are
about (e.g. `incomingXXX` or `outgoingXXX`). It also means you can
actually tree-shake certain features (span creation) out, in theory.
Outgoing request handling remains the same for the time being, once we
decoupled this from the otel http instrumentation we can do something
similar there.
The biggest challenge was how to make it possible to de-compose this
without having to monkey patch the http server twice. I opted to allow
to add callbacks to the `httpServerIntegration` which it will call on
any request. So the `httpServerSpansIntegration` can register a callback
for itself and plug into this with little overhead.

Spotted that we still documented that the root span does not go through
`beforeSendSpan`. This is outdated. Since v9, we also pass the root span
to the callback.

...eLayerExtension` default (#17817)
The default setting for `useLayerExtension` now considers the
`http_proxy` environment variable. When `http_proxy` is set,
`useLayerExtension` will be off by default. If you use a `http_proxy`
but would still like to make use of the Sentry Lambda extension, exempt
`localhost` in a `no_proxy` environment variable.
Fixes: #17804
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Disable `useLayerExtension` by default when `http_proxy` is set
(unless `no_proxy` exempts localhost), add debug warnings, tests, and
changelog entry.
> 
> - **aws-serverless**:
> - Consider proxy env vars when defaulting `useLayerExtension` in
`packages/aws-serverless/src/init.ts`.
> - New `shouldDisableLayerExtensionForProxy()` checks `http_proxy` and
`no_proxy` (localhost exemptions).
> - Update default: enable only if using Lambda layer, no custom tunnel,
and no proxy interference.
> - Add debug warnings when disabling due to proxy and when tunneling
via extension.
> - **Tests**:
> - Expand `packages/aws-serverless/test/init.test.ts` to cover
proxy/no_proxy scenarios, explicit overrides, and env cleanup.
> - **Docs/Changelog**:
> - Add Important Changes note explaining new default behavior and how
to re-enable with `no_proxy` exemptions.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
53e333f. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

This pull request introduces instrumentation for Nuxt middleware,
ensuring that all middleware handlers are automatically wrapped with
tracing and error reporting functionality. The integration is achieved
through build-time transformation.
recap:
* Adds a new build-time Rollup plugin
(`middlewareInstrumentationPlugin`) that automatically wraps all
detected middleware handlers with Sentry instrumentation during the
Nitro build process.
* Implements the `wrapMiddlewareHandler` utility, which wraps middleware
handlers to start a Sentry span, capture request data, record
exceptions, and flush events in serverless environments.
* Updates the Nuxt module setup to inject Sentry middleware imports and
instrumentation hooks during initialization, ensuring the new tracing
logic is included in server builds.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds build-time wrapping of Nuxt server middleware with Sentry spans
and error capture, plus Nuxt 3/4 e2e and unit tests.
> 
> - **SDK/Runtime**:
> - Implement `wrapMiddlewareHandlerWithSentry` in
`packages/nuxt/src/runtime/hooks/wrapMiddlewareHandler.ts` to start
spans, set attributes (op, origin, route, method, headers), handle hook
arrays (`onRequest`, `onBeforeResponse`), and capture errors.
> - Add middleware build-time transformation via
`packages/nuxt/src/vite/middlewareConfig.ts` (server import + Rollup
plugin to wrap `defineEventHandler`/`eventHandler`).
> - Integrate instrumentation in `packages/nuxt/src/module.ts` by
calling `addMiddlewareImports` and `addMiddlewareInstrumentation` during
Nitro init when server config is present.
> - **Tests**:
> - Add e2e apps and Playwright tests for Nuxt 3 and Nuxt 4
(`dev-packages/e2e-tests/test-applications/nuxt-{3,4}`) covering span
creation, attributes, parent-child relationships, and error propagation
across hooks and arrays.
> - Add unit tests for wrapper behavior in
`packages/nuxt/test/runtime/hooks/wrapMiddlewareHandler.test.ts`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
9a4a1f3. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->