meta(changelog): Update changelog for 10.67.0#22382
Merged
Merged
Conversation
[Gitflow] Merge master into develop
…ice (#21959) Prevent infinite recursion when console is instrumented twice `instrumentConsole()` could run more than once against the same module state — e.g. a bundler-duplicated `@sentry/core` (common in React Native) or repeated instrumentation. Because the wrapper resolves the original method dynamically rather than from its closure, a second wrap made `originalConsoleMethods[level]` point at a Sentry wrapper. From then on every `console.*` call (and every `consoleSandbox` restore) re-entered the wrapper, recursing until the stack overflowed. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…n integration (#22146) Adds `koaChannelIntegration` in `@sentry/server-utils` for injecting orchestrion channels into `koa`. A subscriber wraps each registered layer in a span-creating proxy. Span-helpers are ported from the vendored instrumentation, preserving span names (but adapting to [new conventions](getsentry/sentry-conventions#472)). Also upgraded `@apm-js-collab/tracing-hooks` to get this: apm-js-collab/tracing-hooks#45 to be released (lets us actually patch `koa` - see 1. iteration below). <details> <summary>1. iteration</summary> One thing to know for review: **we instrument `koa-compose`, not `use` from koa.** koa's `use` lives in koa's main entry (`lib/application.js`), and transforming a package's main entry forces its top-level `require` chain through Node's `require(esm)` bridge, which throws on Node < 24.13. 1. Orchestrion instruments by rewriting a module's source at load time (via the ESM load hook). 2. `use` lives in koa's main entry (`lib/application.js`), so to instrument it we transform that file. But transforming a main entry pulls its whole top-level `require` chain into the loader's handling --> and that changes how those `require`s are loaded (through the ESM→CommonJS translator, not the normal sync require path). 3. `koa` is CJS (but support ESM). When `import`ing koa, it loads a shim that loads the CJS code: `import 'koa'` → `dist/koa.mjs` (a ESM shim) → `import '../lib/application.js'` (CJS). That CJS entry has a top-level `require('is-generator-function')`. 4. `is-generator-function` → `require('generator-function')`, and `generator-function` points at an `.mjs` file, which in turn imports `./index.js`. --> So the top-level `require` in koa's `application.js` (CJS) becomes `require(esm)` of an ESM file importing a CJS file. 5. On Node < 24.13 (we pin 20.19.5), the loader can't pre-link this dual-package shape into the `require(esm)` cache, so it throws `request for './index.js' is not in cache`. The failing chain: ``` koa/lib/application.js (CJS) └─ require('is-generator-function') (CJS) └─ require('generator-function') → require(esm) → require.mjs (ESM) └─ import './index.js' (ESM importing CJS) ``` `koa-compose` is koa's zero-dependency dispatch engine, so it's safe to transform, and `compose(app.middleware)` sees the same layers `use` would. Since `@koa/router` also calls `compose` per request, the subscriber uses `getActiveSpan()` to only wrap at app startup (no active span) and skip the per-request router composition.</details> Closes #20758 Linear: https://linear.app/getsentry/issue/JS-2409/rewrite-opentelemetryinstrumentation-koa-to-orchestrion
Update name of `queryParams` to `urlQueryParams` to reduce ambiguity with other query types. We can just use `urlQueryParams` everywhere in the code as we resolve the option once and then use just the new value: ```ts urlQueryParams: dc.urlQueryParams ?? dc.queryParams ?? base.urlQueryParams, ``` Develop Docs PR: getsentry/sentry-docs#18703 The PR is not merged (as of now) but this change was already discussed to be made.
Pinia 4 has no API-changes, so we only need to update peer-dependency range. Also updates Pinia in the E2E test. Pinia Release: https://github.com/vuejs/pinia/releases/tag/v4.0.0 Closes #22320 Co-authored-by: Cursor <cursoragent@cursor.com>
fix: #22296 fix: JS-3054
Since we missed the Pinia major version (see issue #22320), I added some libraries to our framework update watcher.
Workflow file is not posted. See action run: https://github.com/getsentry/sentry-javascript/actions/runs/29232933372/job/86760964358
) This PR fixes some issues with capturing runtime orchestrion diagnostics: - Handles and logs errors! - Configures the hook for the async loader and require hook Notes: - This is all really nasty and can be reduced considerably when we drop support for Node without `require(esm)`. - We have to block `registerDiagnosticsChannelInjection` from running on the loader thread or it crashes! - I dropped all the usage of `DEBUG_BUILD` because this code is all server side and we want these to always be captured when `debug: true`. Probably worth adjusting the ai prompt to reflect this!
…ode (#22293) In orchestrion mode, a v4 Vercel AI tool error was reported to Sentry **twice**: once by the channel subscriber (`captureToolError`, which captured the raw error mid-execution) and again when the SDK's wrapped `AI_ToolExecutionError` bubbled up to the app's error handling (express handler, or the global unhandled-rejection handler). The two events are different objects (raw error vs. wrapper), so Sentry's already-captured dedup didn't collapse them. This also caused a flaky test: `captures error in tool in express server` used `.unordered()` with a single `event` expect and matched whichever of the two error envelopes arrived first — when the express-handler envelope won the race, the tool-tag assertions failed. _Root cause_ The channel subscriber's tool-`execute` wrapper always captured the thrown error and re-threw. That capture is required on **v5**, where `executeTools` swallows the rejection into `tool-error` content so it never surfaces otherwise. On **v4** the rejection instead bubbles out of the `ai` call, so it is already captured by the app's error handling — making the channel capture a duplicate. The OTel integration never had this problem because it doesn't self-capture v4 thrown tool errors; it lets them bubble. Changes: - The orchestrion subscriber now only self-captures tool errors when the enclosing operation swallows them (v5+, detected via the `'v1'` model spec version already used elsewhere in the file). On v4 it marks the tool span as errored and lets the error bubble, matching the OTel path — so a single error event is reported. - To preserve trace correlation for bubbled errors, the subscriber stamps the operation's call-site span onto the error via `_sentry_active_span`, reusing the exact mechanism the OTel integration already uses (`onunhandledrejection` restores it at capture time). Without this, an unhandled rejection in a non-OTel (orchestrion) process would start its own trace instead of correlating to the transaction. - Both of the above are per-operation facts keyed by the operation span, so they're stored together in a single `WeakMap<Span, OperationErrorInfo>` (`{ callSiteSpan, toolErrorsBubbleToCaller }`) written once at operation start, rather than two parallel collections. - Tests updated: both v4 error-in-tool scenarios now assert a single `AI_ToolExecutionError` event correlated to the transaction, in both orchestrion and OTel modes. Fixes the flaky `suites/tracing/vercelai/test.ts > ... > captures error in tool in express server [cjs]`. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
I missed this commit off of #22327. This ensure that we only skip registering the hooks on the loader thread which means Sentry in a worker thread can still hook loading.
…annel (#22331) Merges the express `route`/`use` registration channels into a single per-module `register` channel to reduce the number of tracing channels — the subscriber treats both identically, so there's no behavior change. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…esponses/conversations (#22332) Points the OpenAI `responses` and `conversations` APIs at the existing `chat` channel to reduce the number of tracing channels — all three already report the same `chat` operation with identical span handling, so there's no behavior change. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…2313) The Cloudflare integration tests were already testing all AI integrations, but used mocks. I changed the following in all tests: - Removed the `mocks.ts` and changed it to the actual package - Instead the `.fetch` is being mocked - Aligned the assertions
….43.0 in the opentelemetry group (#22333) Bumps the opentelemetry group with 1 update: [@opentelemetry/semantic-conventions](https://github.com/open-telemetry/opentelemetry-js). Updates `@opentelemetry/semantic-conventions` from 1.42.0 to 1.43.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/open-telemetry/opentelemetry-js/releases">@opentelemetry/semantic-conventions's releases</a>.</em></p> <blockquote> <h2>semconv/v1.43.0</h2> <h2>1.43.0</h2> <h3>:rocket: Features</h3> <ul> <li>feat: update semantic conventions to v1.43.0 <a href="https://redirect.github.com/open-telemetry/opentelemetry-js/pull/6883">#6883</a> <ul> <li>Semantic Conventions v1.43.0: <a href="https://github.com/open-telemetry/semantic-conventions/blob/main/CHANGELOG.md#v1430">changelog</a> | <a href="https://opentelemetry.io/docs/specs/semconv/">latest docs</a></li> <li><code>@opentelemetry/semantic-conventions</code> (stable) changes: <em>1 added export</em></li> <li><code>@opentelemetry/semantic-conventions/incubating</code> (unstable) changes: <em>1 added export</em></li> </ul> </li> </ul> <h4>Stable changes in v1.43.0</h4> <!-- raw HTML omitted --> <pre lang="js"><code>TELEMETRY_SDK_LANGUAGE_VALUE_KOTLIN // "kotlin" </code></pre> <!-- raw HTML omitted --> <h4>Unstable changes in v1.43.0</h4> <!-- raw HTML omitted --> <pre lang="js"><code>ATTR_AZURE_RESOURCE_GROUP_NAME // azure.resource_group.name </code></pre> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/9b05f668ee7ab884a44b04b504e0baaff6c6d2b2"><code>9b05f66</code></a> chore: prepare next release (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6906">#6906</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/0f18798b3100412ddabb0b720384caed4e08643c"><code>0f18798</code></a> feat(semantic-conventions): update semantic conventions to v1.43.0 (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6883">#6883</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/bbcdfa8ccd6de110a1a07b40371d07ef455c8851"><code>bbcdfa8</code></a> chore: update workflow to the shared one (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6904">#6904</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/e6a57765f8c4ace29f47b435c690994382709d28"><code>e6a5776</code></a> chore(deps): update dependency typedoc to v0.28.20 (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6898">#6898</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/8bec6624137bbef296dbb1969fc9fb3773a36317"><code>8bec662</code></a> feat(propagator-jaeger): deprecate JaegerPropagator (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6893">#6893</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/20e3abe89cd646936c5433e95814d358896aba10"><code>20e3abe</code></a> chore: add workflow for first time contributor (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6896">#6896</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/fda8f31b1f036a149de00cf7fb379e82cfa1987f"><code>fda8f31</code></a> chore: bump to typescript@5.2.2 (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6888">#6888</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/3394c3e234ef28a9538610f14ee4f6ff19abeb11"><code>3394c3e</code></a> fix(sdk-trace): sample ratio 1 upper-bound trace IDs (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6890">#6890</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/2568ac16e6f02da85a8893de3ad61dc2f418e95f"><code>2568ac1</code></a> chore: clean up some deps and devDeps in exporter packages (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6892">#6892</a>)</li> <li><a href="https://github.com/open-telemetry/opentelemetry-js/commit/0fd7fac15f4afcc26c5c233fb4e7725f74ce2616"><code>0fd7fac</code></a> test(exporter-metrics-otlp-*): return response to allow process exit (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js/issues/6889">#6889</a>)</li> <li>Additional commits viewable in <a href="https://github.com/open-telemetry/opentelemetry-js/compare/semconv/v1.42.0...semconv/v1.43.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…22142) The integration subscribes to the `orchestrion:<smithy-pkg>:send` channels the transform injects into the smithy `Client.prototype.send` (`@smithy/core`, `@smithy/smithy-client`, `@aws-sdk/smithy-client`) and emits a client rpc span per command (`rpc.system`/`rpc.method`/`rpc.service`, `cloud.region`, request id metadata), with a distinct `auto.aws.orchestrion.aws_sdk` origin. The per-service extension registry (span names, messaging/db/gen_ai attributes, trace propagation) starts empty and mirrors the OTel integration's `ServiceExtension` contract; the services are ported one group at a time in the follow-up PRs of this stack. The OTel instrumentation was only added to the `@sentry/aws-serverless` SDK, but it is useable in other SDKS so the orchestrion version lives in server-utils now. ## User-facing differences to the vendored OTel instrumentation - span origin is `auto.aws.orchestrion.aws_sdk` instead of `auto.otel.aws` - spans started after SQS `ReceiveMessage` parent to the surrounding span instead of the receive span; receive-to-consumer linkage uses span links (messaging PR) - outgoing SQS/SNS/Lambda trace propagation uses `sentry-trace`/`baggage` message attributes instead of W3C headers (messaging PR) - errored spans may carry `aws.request.id`/`aws.request.extended_id` where the OTel path missed them (`$metadata` fallback) Part of #20946
…epFunctions aws-sdk extensions (#22164) Ports the attribute-only service extensions from the OTel aws-sdk integration to the orchestrion channel integration and registers them in the service registry: * S3: `aws.s3.bucket` * Kinesis: `aws.kinesis.stream.name` * DynamoDB: `db.*` and `aws.dynamodb.*` request/response attributes * SecretsManager: `aws.secretsmanager.secret.arn` (request and response) * StepFunctions: state machine / activity ARNs Straight ports; none of these inject trace propagation or change span lifecycle. Part of #20946
…trace propagation (#22165) Ports the messaging service extensions from the OTel aws-sdk integration to the orchestrion channel integration and registers them in the service registry: * SQS: producer/consumer span kinds and names, `messaging.*` attributes, trace propagation into outgoing `MessageAttributes` (single and batch), and span links from received messages via the propagated headers * SNS: producer span kind/name for `Publish`, `messaging.*` and topic ARN attributes, trace propagation into `MessageAttributes` * Lambda: `faas.*` attributes for `Invoke`, trace propagation into the base64 `ClientContext` (respecting the 3583 byte cap) Propagation writes Sentry-native `sentry-trace`/`baggage` headers derived from the request span instead of OTel `propagation.inject`, and the SQS receive side reads them back with `propagationContextFromHeaders`. Part of #20946
…ostics-channel opt-in (#22143) Wires the orchestrion aws-sdk channel integration into `@sentry/aws-serverless`, where the OTel `Aws` integration ships as a default today. `@sentry/node` exposes a reusable `applyDiagnosticsChannelInjectionIntegrations` helper (extracted from its `getDefaultIntegrations`), and `@sentry/aws-serverless` uses it to swap the OTel `Aws` integration for the channel version when the app opts in via `experimentalUseDiagnosticsChannelInjection()` (now re-exported from the aws-serverless SDK). No change when the opt-in isn't used. The existing `aws-integration` node-integration-tests assert the swapped origin via `isOrchestrionEnabled()`, so both the OTel and diagnostics-channel paths are covered by the same suites across both smithy stacks (latest + legacy `3.1041.0`) and ESM/CJS. Only the expected origin is parametrized. Part of #20946
…n tests (#22166) Ports the BedrockRuntime gen_ai service extension from the OTel aws-sdk integration to the orchestrion channel integration: chat span name and request parameters for `Converse`/`ConverseStream`, per-model-family request body parsing for `InvokeModel`/`InvokeModelWithResponseStream` (titan, nova, claude, llama, cohere, mistral), token usage and finish reasons from responses, and deferred span end for the streaming commands (the span ends when the wrapped stream is consumed). Adds nock-mocked integration tests for the non-streaming `Converse` and `InvokeModel` commands, asserted against both the OTel and diagnostics-channel paths. The streaming commands use the AWS binary eventstream framing which nock cannot mock, so they stay untested here. This completes orchestrion parity with the OTel aws-sdk integration. ## User-facing differences to the vendored OTel instrumentation * `ConverseStream` callers receive the original response object with its `stream` wrapped in place, instead of a new object (a channel subscriber can't replace the resolved value); relevant only to identity-sensitive code Fixes #20946
`@apm-js-collab/code-transformer` was only ever a dependency to access the `InstrumentationConfig` type. This is now re-exported from `@apm-js-collab/code-transformer-bundler-plugins/core` at the root of `@sentry/server-utils` so it can be used wherever we need it.
Port the OTel mongoose intstrumentation to Orchestrion. Add Deno integration, and node integration tests for mongoose versions 5, 6, 7, 8, and 9. Native diagnostics channel used on Mongoose versions supporting them (ie, 9.7+). Fix: JS-2412 Fix: #20761
…alse } (#22300) Closes #22220 ## Summary `ReplayIntegration.stop()` always force-flushes the pending segment when `recordingMode === 'session'`, with no public way to opt out. Because Replay envelopes bypass `beforeSend`, consent-gated setups (CookieYes / OneTrust / Usercentrics / custom CMPs) that call `stop()` on consent withdrawal end up sending the buffered segment **after** the user revoked consent. The only workaround today is reaching into the private `_replay` field to call the internal `stop({ forceFlush: false })`, which isn't something we want to depend on in production code. This exposes the already-existing internal `forceFlush` control on the public integration API. ## Changes * `stop()` now accepts an optional `{ flush?: boolean }`: ```ts public stop(options?: { flush?: boolean }): Promise<void> { if (!this._replay) { return Promise.resolve(); } return this._replay.stop({ forceFlush: options?.flush ?? this._replay.recordingMode === 'session', reason: 'manual', }); } ``` * **Defaults to the current behavior** (`flush` unset → flush when `recordingMode === 'session'`), so it's fully backwards compatible and safe to land in v10. * `flush: false` stops recording without sending the pending segment. * Added a doc comment noting the caveat (per @isaacs' comment on the issue): `flush: false` only suppresses the *pending/final* segment — it does **not** retract segments already sent earlier during `session` recording. * Added tests for both `flush: false` (does not send) and `flush: true` (sends) in `session` mode. ## API naming The issue proposed matching the internal `forceFlush` name, and @isaacs flagged that `forceFlush` leaks an internal term into the public surface. I went with the public-facing `flush` (`stop({ flush: false })`) since it reads better as public API, while mapping to the internal `forceFlush`. Happy to switch to `forceFlush` (matching the internal name, least surprising for anyone who already knows it) or a dedicated `discard`-style option instead — whichever the team prefers. ## Verification * `packages/replay-internal` test suite: **476 passed** (incl. 2 new `stop` tests). * Changed files are `oxfmt`-clean and typecheck cleanly. - [X] Added tests for the new behavior. - [X] Test suite passes for the affected package. - [X] Linked the related issue (#22220).
…-origin realms (#22273) The default `functionToStringIntegration` patches `Function.prototype.toString`. The patched function reads the Sentry carrier off `getClient()` (→ `getMainCarrier()` → `getSentryCarrier(GLOBAL_OBJ)` → `GLOBAL_OBJ.__SENTRY__`) on **every** `.toString()` invocation. `GLOBAL_OBJ` is a `WindowProxy` in browser realms. When its browsing context is later navigated cross-origin while code from the old realm can still be invoked (e.g. a parent window holding a reference into a same-origin child iframe whose `src` changed to a cross-origin URL), the `__SENTRY__` read throws a `SecurityError`. Because the patch lives on `Function.prototype`, the throw is triggered by *any* third-party `.toString()` call, converting harmless introspection into uncatchable `SecurityError` noise that Sentry then reports as unhandled-rejection events. ## Root cause The native `Function.prototype.toString` never throws for these calls — the throw is introduced solely by the integration's internal carrier access. The fix wraps the patch body in a `try/catch` and falls back to `originalFunctionToString.apply(this, args)`, mirroring the defensive style already used around the patch installation. This keeps the unwrap behavior intact for live realms and degrades to exact native semantics when the carrier read throws. Fixes #21965 🤖 Generated with [Claude Code](<https://claude.com/claude-code>) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Rewrites the vendored `RemixInstrumentation` (an OpenTelemetry `InstrumentationBase` that patched `@remix-run/server-runtime`) to a diagnostics-channel listener, with orchestrion injecting the channels into the instrumented module at build time. ### SDK changes * `@sentry/server-utils` — populated the orchestrion config for `@remix-run/server-runtime` (`orchestrion/config/remix.ts`) * `@sentry/remix` — adjusted the `remixIntegration` so it runs either OTEL-based instrumentation, or prchestrion-based instrumentation if opted in. ### E2E changes * Folded the standalone `remix-orchestrion` test app into `create-remix-app-v2` as an `INJECT_ORCHESTRION`-gated `sentryTest` variant, so one codebase runs both the OpenTelemetry and orchestrion paths (build-time injection via the orchestrion Vite plugin, DB routes + docker for mysql/ioredis, and a build-injection assertion). The base transaction tests run in both variants as a parity check. * To make `@remix-run/server-runtime` reachable by the build-time transform, `@remix-run/node` is force-bundled (it re-exports server-runtime, which otherwise stays external and is loaded by `remix-serve` at runtime, outside the Vite bundle). Fixes #20910 --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sets the `navigation.route.id` attribute on pageload and navigation spans, sourced from the Vue Router route name (`to.name`). ref #22069 Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…L queries (#22376) `agents` generates a lot of internal spans, which are mainly noise. The `workers-sdk` actually proofs that the summary with a `cf_` prefix are internal. So these are now filtered by default. I thought about having [an option](689e90c) to enable them, but I don't think this adds a lot of value. <img width="1051" height="991" alt="Screenshot 2026-07-17 at 22 38 30" src="https://github.com/user-attachments/assets/565af8c4-3330-4dc3-91be-f772f16e6d93" /> In case users have `cf_` prefixed spans in their app they can use: `durableObjectSqlSpanAllowlist: []` to allow them, this would also be helpful if you want to get cf internal spans activated.
Switches our ci workflows to use openrouter. Key is already added.
closes #20839 <br>closes #20839 This is instrumenting `workers-ai`, but it needs to be wrapped, as in Cloudflare there is no monkey patching for bindings. In a follow-up PR this will be included in the `instrumentEnv` within Cloudflare. Tbh I would have added this into `packages/cloudflare`, but all AI integrations do live in core, and there are also some utils which are only there and would have needed to export, such as `endStreamSpan` and all the gen-ai-attributes. The downside of this is that the workers-ai types needed to be vendored in (in the `packages/cloudflare` we could have taken them from the `@cloudflare/workers-types` package. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…ntation (#22126) This auto-wraps workers-ai bindings via `instrumentEnv`. Unfortunately locally there is no AI binding available and would require an actual LLM on Cloudflare, so in the integration tests there is only a MockAi. However, the autobinding is tested via unit tests and have the same pattern as the other instrumentations. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
andreiborza
requested review from
JPeer264,
isaacs,
logaretm and
msonnb
and removed request for
a team
July 20, 2026 11:10
chargome
reviewed
Jul 20, 2026
nicohrubec
approved these changes
Jul 20, 2026
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
andreiborza
force-pushed
the
prepare-release/10.67.0
branch
from
July 20, 2026 11:29
58ea34b to
3c20967
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 3c20967. Configure here.
chargome
approved these changes
Jul 20, 2026
Contributor
size-limit report 📦
|
msonnb
approved these changes
Jul 20, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
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.