[pull] master from getsentry:master #42
Open
Conversation
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
) The main OpenAI APIs are the [completions](https://platform.openai.com/docs/api-reference/completions/create) and [responses](https://platform.openai.com/docs/api-reference/responses/create) API. Currently we truncate messages sent to the API only if the user input is an array of strings. This works for the completions, but not for the responses API (where the input is a plain string). Updated the truncation logic to also truncate if the input is a plain string (+ test to verify everything works now as expected).
Adds remaining node-based exports for metrics closes #18152
…ages (#18157) This PR adds [truncation support for LangChain integration request messages](#18018). All messages already get normalized to arrays of messages, so here we need no case distinction for strings. Adds tests to verify behavior for 1. simple string inputs and 2. conversations in the form of arrays of strings. Closes #18018
meta(changelog): Update changelog for 10.25.0
Fixes faulty test assertions where we asserted for certain properties to _not_ be in an object but used `toMatchObject` to do so.
[Gitflow] Merge master into develop
…captureConsoleIntegration` (#18096) This patch creates a synthetic exception already within the captureConsole handler, so that we minimize the number of Sentry stack frames in the stack trace. It also adjusts the `Client::captureMessage` method to favor an already provided `syntheticException` over the one it would create by itself.
We needed the override because version 10.0.1 didn't have a valid package.json (embroider-build/embroider#2609). They released version 10.0.2 now.
Two changes: 1. Reduce bundle size slightly by optimizing `setTag` (+ adding some more tests around setTag(s)) 2. Adjust the integration test message since we no longer classify the SUT behaviour as a bug
…18172) This PR attempts to fix #18001 by not wrapping the middleware files if Next.js 16 is the current version and is in standalone output mode which is the problematic scenario. Investigation: - Next.js renames `proxy` to `middleware` under the hood. - By wrapping the middleware a `proxy.js` entry is produced in `middleware.js.nft.json` which wouldn't be there otherwise, meaning if we don't wrap it then that entry doesn't get produced. So it seems like `@vercel/nft` is somehow adding the `proxy` file as a dependency of itself which fails to copy to the output directory because it was already copied and renamed to `proxy.js` or at least that is what I'm guessing is happening.
This came up while working on improvements for React Router wildcard routes. Looks like the successful browser `idleSpans` are reported with `unknown` status at the moment.
…ple times(#17972) When using higher-level integrations that wrap underlying libraries, both the wrapper integration and the underlying library integration can instrument the same API calls, resulting in duplicate spans. This is particularly problematic for: - LangChain wrapping AI providers (OpenAI, Anthropic, Google GenAI) - Any future providers that wrap other providers We expose 3 internal methods ```js _INTERNAL_skipAiProviderWrapping(providers: string[]) _INTERNAL_shouldSkipAiProviderWrapping(provider: string) _INTERNAL_clearAiProviderSkips() ``` To bail out of instrumenting providers when they are on the skip list. These are internal methods not meant for public consumers and may be changed or removed in the future. --------- Co-authored-by: Andrei Borza <andrei.borza@sentry.io>
As discussed moving the AI integrations from core/utils to core/tracing.
…8191) I guess this got through CI because we test latest 18 rather than 18.0.0. This breaks [some supported Electron versions](https://github.com/getsentry/sentry-electron/actions/runs/19306230917/job/55215745023) which are using >18.0.0 but <18.19.0. This wont have impacted almost anyone else because Otel requires 18.19.0! ``` [App] [ Main] App threw an error during load [App] [ Main] file:///home/runner/work/sentry-electron/sentry-electron/test/e2e/dist/error-after-ready/node_modules/@sentry/node-core/build/esm/integrations/pino.js:1 [App] [ Main] import { tracingChannel } from 'node:diagnostics_channel'; [App] [ Main] ^^^^^^^^^^^^^^ [App] [ Main] SyntaxError: The requested module 'node:diagnostics_channel' does not provide an export named 'tracingChannel' [App] [ Main] at ModuleJob._instantiate (node:internal/modules/esm/module_job:124:21) [App] [ Main] at async ModuleJob.run (node:internal/modules/esm/module_job:190:5) [App] [ Main] A JavaScript error occurred in the main process ```
With this PR users can set their min replay duration to max 50s, previously this was capped at 15s. We cannot bump this value further as this would lead to dropping buffered replays (we keep max. 60s in-memory at this point) closes #18109 --------- Co-authored-by: Andrei <168741329+andreiborza@users.noreply.github.com>
…ion (#18195) ## Problem The Spotlight configuration logic had a precedence bug where when `spotlight: true` was set in config AND the `SENTRY_SPOTLIGHT` environment variable contained a URL string, the SDK would incorrectly use `true` instead of the URL from the environment variable. According to the [Spotlight specification](https://raw.githubusercontent.com/getsentry/sentry-docs/b38e3b307f900665a348f855559ac1d1c58914cc/develop-docs/sdk/expected-features/spotlight.mdx), when `spotlight: true` is set and the env var contains a URL, the URL from the env var should be used to allow developers to override the Spotlight URL via environment variables. **Previous behavior:** ```typescript // Config: spotlight: true // Env: SENTRY_SPOTLIGHT=http://custom:3000/stream // Result: spotlight = true ❌ (incorrect) ``` **Expected behavior per spec:** ```typescript // Config: spotlight: true // Env: SENTRY_SPOTLIGHT=http://custom:3000/stream // Result: spotlight = "http://custom:3000/stream" ✅ (correct) ``` ## Solution Fixed the precedence logic in `getClientOptions()` to properly implement the specification: 1. `spotlight: false` → Always disabled (overrides env var) 2. `spotlight: string` → Uses the config URL (ignores env var) 3. `spotlight: true` + env var URL → **Uses the env var URL** (the bug fix) 4. `spotlight: true` + env var truthy → Uses default URL 5. No config + env var → Parses and uses env var The implementation reuses the existing `envToBool()` utility to avoid code duplication. ## Changes - Fixed Spotlight precedence logic in `packages/node-core/src/sdk/index.ts` - Added 12 comprehensive test cases covering all precedence scenarios in `packages/node-core/test/sdk/init.test.ts` - Updated CHANGELOG.md ## Test Coverage The new tests cover: - ✅ Env var only: truthy values, falsy values, URL strings - ✅ Config only: `true`, `false`, URL string - ✅ Precedence: config `false` overrides env var (URL, truthy, falsy) - ✅ Precedence: config URL overrides env var - ✅ Precedence: config `true` + env var URL uses env var URL (the fix) - ✅ Precedence: config `true` + env var truthy uses default URL ## Related - Original Spotlight implementation: #13325 - Spotlight specification: https://spotlightjs.com/ --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
…8194) While investigating [this ticket](https://linear.app/getsentry/issue/JS-657/available-tools-json-should-be-a-stringified-json-array-of-objects-not) I noticed that available tools are sent as a nested instead of a flat array in google genai, which seems like a bug to me. The format I would expect and how we do it in other integrations is: [{tool-definition}, {tool-definition}] What we actually send atm is: [[{tool-definition}], [{tool-definition}]] This PR fixes this to instead send a flat list of tool definitions.
[Linear Ticket](https://linear.app/getsentry/issue/JS-657/available-tools-json-should-be-a-stringified-json-array-of-objects-not) The available tools sent from our SDKs should generally be in the format of a stringified array of objects (where an object stores information about a particular tool). This is true for all AI SDKs except Vercel, where we send an array of strings. This PR fixes this by parsing the available tool array and converting the whole array into a proper string representation.
…igh `normalizeDepth` (#18206) Fixes #18203 ### Problem When using `normalizeDepth: 10` with `captureConsoleIntegration` enabled, Vue VNodes in console arguments would trigger recursive warning spam. Accessing VNode properties during normalization would trigger Vue's reactive getters, which emit console warnings. These warnings would then be captured and normalized again, creating a recursive loop that could generate hundreds of warnings. Note that this only happens in `dev` mode ### Solution Changed `isVueViewModel()` to detect Vue 3 VNodes (`__v_isVNode: true`) in addition to Vue 2/3 ViewModels. VNodes are now identified early in the normalization process and stringified as `[VueVNode]` before their properties are accessed, preventing the recursive warning loop. Some of the properties on the `VNode` can also be reactive, so it can incorrectly add those to a watchEffect or a render function reactive dependencies when accessed by the normalizer. ### Changes - **`packages/core/src/utils/is.ts`**: Added `__v_isVNode` check to `isVueViewModel()`. - **`packages/core/src/utils/normalize.ts`**: Distinguish VNodes from ViewModels in output (`[VueVNode]` vs `[VueViewModel]`). - **Tests**: Added comprehensive unit tests for Vue object detection and integration test that verifies no property access occurs during VNode normalization. --- I couldn't reproduce this exactly in a test with a real vue component, but verified it fixes the reproduction example. The before and after of the captured logs: Before: <img width="1106" height="1137" alt="CleanShot 2025-11-14 at 15 46 30" src="https://github.com/user-attachments/assets/435dbb04-ba3c-430b-8c39-d886f92072e8" /> After: <img width="908" height="768" alt="CleanShot 2025-11-14 at 15 45 15" src="https://github.com/user-attachments/assets/e7d8cca2-a0e1-48bb-9f95-3a39d2164d21" /> As a Vue developer I don't think the loss of information here would help debug anything.
The ErrorBoundary exported in the SDK only works on the client and is not intended to be used. Use react router's error boundary instead: https://docs.sentry.io/platforms/javascript/guides/react-router/#report-errors-from-error-boundaries.
Undo #18524 as the issue has been resolved and `1.25.1` has been released
…#18501) Previously, we only got the body from the `fetch` options. However, some people use the `Request` object which can also contain a body. As this body is a `ReadableStream`, we could only read that async. With `attachRawBodyFromRequest`, the `Request` object is patched to include the raw body as a `Symbol` so it can be read synchronously. Linear ticket (internal): https://linear.app/getsentry/issue/JS-1255/investigate-sdk-issues-causing-all-requests-to-default-to-get
Closes #18539 (added automatically)
This PR adds tracing for tss server functions. To achieve this I added a
new `wrapFetchWithSentry` wrapper that can be used to instrument the tss
server entry point:
```
import { wrapFetchWithSentry } from '@sentry/tanstackstart-react';
import handler, { createServerEntry } from '@tanstack/react-start/server-entry';
const requestHandler = wrapFetchWithSentry({
fetch(request: Request) {
return handler.fetch(request);
},
});
export default createServerEntry(requestHandler);
```
With this we get spans for server functions executed via `fetch` calls
to the server. A limitation of this approach is that out-of-the-box this
will only start a single span for the initial request made to the
server. So for instance if a server function calls another server
function, we will still only get a single span for the outer server
function and users would need to wrap the inner call manually.
Tests added:
- E2E: Basic transaction test to verify that we get spans if a server
function is executed.
- E2E: Another transaction test documenting that users need to manually
wrap "nested" server functions.
- Unit: Tests to verify the sha256 extraction.
Closes #18287
With this PR we get this attributes from the initialization request and response into the `initialize` span: - `mcp.client.name`, `mcp.client.version`, `mcp.client.title` (from request) - `mcp.server.name`, `mcp.server.version`, `mcp.server.title` (from response) - `mcp.protocol.version` (from both request and response) Changes: - Extract client info and protocol version from the `initialize` request and set them on the span after creation in `transport.ts` - Extract server info and protocol version from the `initialize` response in `completeSpanWithResults` and add them to the span - Add two new helper functions `buildClientAttributesFromInfo` and `buildServerAttributesFromInfo` to build attributes directly from `PartyInfo` objects Closes #18532 (added automatically)
The newly released [React Router 7.11.0](remix-run/react-router#14507) introduced vite preview support(remix-run/react-router#14507). This change has a bug that affects SPA mode (`ssr: false`). When building in SPA mode, React Router correctly builds the server bundle (`build/server/index.js`) and then removes it with the message `Removing the server build... due to ssr:false`. The new vite preview implementation doesn't account for this removal and attempts to import the deleted `build/server/index.js` file when starting the preview server, causing: > Cannot find module '/build/server/index.js' Closes #18549 (added automatically)
Add support for scope attributes on logs. For now, only
primitive attribute values are supported despite type declarations of
`Scope.setAttribute(s)` also allowing array attribute values. The reason
for this limited support is that Relay still discards array attribute
values. Therefore, our serialization strategy for now is:
- **As previously**: We continue to stringify non-primitive values for
log/metric attributes
- **New:** We apply only primitive scope attributes on logs/metrics and
discard any non-primitive values
- **Future:** We'll uniformly handle arrays (properly) in v11 (i.e. no
longer stringify them), i.e. treat all attributes equally.
### Usage Example
```ts
Sentry.getCurrenScope().setAttribute('user_is_admin', true);
Sentry.logger.info(`user ${user.id} logged in`, { activeSince: 100 });
Sentry.logger.warn('unsupported version');
// `user_is_admin` attribute is applied to both logs
```
Some behavior notes:
- Scope attributes are merged from all active scopes (current,
isolation, global scopes) when the log is captured
- Log attributes have precedence over scope attributes
closes #18159
…es/e2e-tests/test-applications/node-express-v5 (#18550) Bumps [@trpc/server](https://github.com/trpc/trpc/tree/HEAD/packages/server) from 10.45.2 to 10.45.3. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/trpc/trpc/commits/HEAD/packages/server">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 merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/getsentry/sentry-javascript/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
meta(changelog): Update changelog for 10.32.0
chore(ci): Skip build job when no code changes present
[Gitflow] Merge master into develop
If the error is caught with the hono error handler, no `trace` data was sent alongside the event. This PR fixed this. Before: <img width="216" height="80" alt="image" src="https://github.com/user-attachments/assets/35bc99b7-4a59-40e3-aad8-10130f816d68" /> After: <img width="248" height="85" alt="image" src="https://github.com/user-attachments/assets/dbc89577-0832-4166-8532-5210dc5e5d99" />
This removes a test that only asserted on successful deployment of a static cloudflare app. No actual tests. I don't think there's much value in this but it required a repo-specific env secret we can now get rid of. (fwiw, long-term we definitely want cloudflare-deployed e2e tests but we'll likely need a better test setup anyway) Closes #18568 (added automatically)
Explicitly enable `any` usage in typescript in: - `dev-packages`, since those are largely integration and E2E tests. (This is done with the addition of a `dev-packages/.eslintrc.js` file.) - `packages/*/test/`, since those are all tests. (This is done with a rule override added to the root `.eslintrc.js` file.) - Several one-off allowances, generally for vendored types from third party sources, and cases involving function type extension/overriding that TypeScript can't follow. (These are done with file/line overrides, explicit `as` casting, and adding type inference to the `isInstanceOf` method.) In other places (ie, in exported production code paths), replace `any` with `unknown`, and upgrade the `@typescript/no-explicit-any` lint rule to an error. This silences a lot of eslint warnings that were habitually ignored, and encourages us to not opt out of strict type safety in our exported code.
Makes sure that `gen_ai.input_tokens` value contains `gen_ai.input_tokens.cached`
meta(changelog): Update changelog for 10.32.1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )