meta(changelog): Update changelog for 10.34.0 #18820
Merged
+2,975
−1,100
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
[Gitflow] Merge master into develop
The function became bloated and unreadable. This PR just splits the function and refactors parts into utils. Closes #18778 (added automatically)
(closes #18449) (closes [JS-1281](https://linear.app/getsentry/issue/JS-1281/appending-hostname-to-fetch-error-messages-breaks-is-network-error-and)) ## Problem As of now, the user has no chance to disallow the manipulation of fetch errors, as we overwrite the error. This can cause problems as seen in #18449. ## Solution This adds a new option for the SDK (please be very critical about that new option here, since `fetch` has no integration this has to be added as a `init` option). `always` is the default and acts the same as it is now, so it is acting as feature: ```ts enhanceFetchErrorMessages: 'always' | 'report-only' | false` ``` To give the user full control of how the errors are done there are 3 settings: | | always | report-only | false | | ------------------------------------------ | ------- | ----------- | - | manipulate the error message directly | ✅ | ❌ | ❌ | send only the changed message to Sentry | ✅ | ✅ | ❌ ## Special attention to reviewers When having `report-only` the generated logs locally differ from the ones in Sentry. I am not quite sure if that would cause any problems. This is the only question which I don't have the answer to yet ## Alternative In case the size increase is too much, we can also have a boolean that disables that (which is on by default) --------- Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
… servers-side middlewares (#18680) This PR adds a middleware wrapper to the `tanstackstart` SDK that allows users to add tracing to their application [middleware](https://tanstack.com/start/latest/docs/framework/react/guide/middleware). Eventually we will want to patch this automatically, but that is a bit tricky since it requires build-time magic. This API provides a manual alternative for now and can later still act as a fallback for cases where auto-instrumentation doesn't work. **How it works** The wrapper patches the middleware `options.server` function that gets executed whenever a middleware is run. Each middleware invocation creates a span with: - op: middleware.tanstackstart - origin: manual.middleware.tanstackstart - name: The instrumentation automatically assigns the middleware name based on the variable name assigned to the middleware. At first I had the issue that if multiple middlewares were used they would be nested (i.e. first middleware is parent of second etc.). This is because the middlewares call `next()` to move down the middleware chain, so trivially starting a span for the middleware execution would actually create a span that would last for the current middleware and any middlewares that come after in the middleware chain. I fixed that by also proxying `next()`, where I end the middleware span and then also reattach the middleware spans to the parent request span instead of the previous middleware span. **Usage** ``` import { wrapMiddlewaresWithSentry } from '@sentry/tanstackstart-react'; const [wrappedAuth, wrappedLogging] = wrapMiddlewaresWithSentry({ authMiddleware, loggingMiddleware, }); ``` **Tests** Added E2E tests for: - if multiple middlewares are executed we get spans for both and they are sibling spans (i.e. children of the same parent) - global request middleware - global function middleware - request middleware - middleware that throws an exception - middleware that does not call `next()` Closes #18666
…meOptions (#18734) closes #18437 closes [JS-1272](https://linear.app/getsentry/issue/JS-1272/extend-bunoptions-with-nodeoptions) This adds a new type `ServerRuntimeOptions` inside `@sentry/core`, a type which can be used for all SDKs without OpenTelemetry suppport. In case OpenTelemetry support is needed `OpenTelemetryServerRuntimeOptions` are exported from `@sentry/node-core`, which extends `ServerRuntimeOptions` with the options which are needed to support OTel. For now we don't have a nice testing strategy for Bun yet, and I didn't want to copy paste all Node integration/e2e tests just for this, I'm still up for suggestions.
…ons (#18800) I was playing around with #15466 and saw that the span names for the Prisma integration are different than the ones with actual OTel support, such as `@sentry/node`. Cloudflare (no `prisma:client:` prefix): <img width="200" height="978" alt="Screenshot 2026-01-13 at 15 48 41" src="https://github.com/user-attachments/assets/6b70a719-3c62-4799-af9c-cc15fe5aef8e" /> Express / Node (prefix is there): <img width="200" height="917" alt="Screenshot 2026-01-13 at 17 18 05" src="https://github.com/user-attachments/assets/e4677cff-b3d9-4695-871a-e64ad05b4810" /> Within the `@prisma/instrumentation`, which is used for our integration, the name [is added properly](https://github.com/prisma/prisma/blob/d4ec055ee9e13e62351bf72643fc978b3d315ae3/packages/instrumentation/src/ActiveTracingHelper.ts#L83), but the `options` are not updated on purpose, as the source of truth is the `name` itself - OTel also uses the name directly: https://github.com/open-telemetry/opentelemetry-js/blob/87a0b455e5f7f36d9b05b41b6bf11d114dcc854c/packages/opentelemetry-sdk-trace-base/src/Tracer.ts#L149 There is no further explanation in #16714 why [the `name` came before the spreading `options`](https://github.com/getsentry/sentry-javascript/pull/16714/files#diff-595e62985088cbceb347c68deb88b69569b35edee895929d72a7f690ac13ecf7R59). --- With this PR the Prisma integration does work correctly: <img width="200" height="843" alt="Screenshot 2026-01-13 at 17 23 06" src="https://github.com/user-attachments/assets/39fa89a3-9b31-4640-ac0c-a517d6457b62" /> --- Since the same code was copied over to Deno, I also fixed it there.
The `remix-hydrogen` E2E test started failing, pinning for now. Closes #18814 (added automatically)
…ap` (#18809) A customer experienced the following issue on iOS Safari 18.6.2: `TypeError: WeakMap keys must be objects or non-registered symbols`. The culprit is probably in web vitals `initUnique` function (which is vendored in). This fix adds a try/catch to handle edge cases where invalid keys are passed to WeakMap, returning a new instance without caching when validation fails. Closes #18810 (added automatically) Co-authored-by: Nicolas Hrubec <nico.hrubec@sentry.io>
[Sentry changed IPs](https://status.sentry.io/incidents/qmh29yyv8bbv) and this caused problems with client report sending. The current problem is that client report sending is stuck in a loop if the client report itself cannot be sent: `Event fails → Client Report #1 fails → Client Report #2 fails → Client Report #3 fails → ∞` With this fix, failed client reports are not sent anymore to prevent this infinite feedback loop. The offline transport already drops client reports when they cannot be sent: https://github.com/getsentry/sentry-javascript/blob/1b41126666e27a311884cf6f7c1ef915f95477de/packages/core/src/transports/offline.ts#L83-L86 I tested this locally by adding an entry to `/etc/hosts`: `0.0.0.0 o1.ingest.sentry.io` (the example in the issue below) Closes #18802
…m client bundle (#18798) Added a new `routeManifestInjection` configuration option that allows users to exclude specific routes from the route manifest injected into the client bundle. This addresses concerns about sensitive or unreleased route patterns being exposed in the client-side code. This also deprecated `disableManifestInjection` option since it would be possible to have conflicting options present which wouldn't be a great DX. Users can disable it entirely by passing `false`, otherwise they can use an object with an `exclude` property. The property can be an array of string/regex values, or a predicate function. The value typings prevent disabling the manifest and excluding it at the same time, also deprecation annotations and build-time warnings should point users towards the new option. ```ts // Disable route manifest injection entirely withSentryConfig(nextConfig, { routeManifestInjection: false }) // Exclude specific routes withSentryConfig(nextConfig, { routeManifestInjection: { exclude: [ '/admin', // Exact match /^\/internal\//, // Regex: routes starting with /internal/ /\/secret-/, // Regex: routes containing /secret- ] } }) // Exclude using a function withSentryConfig(nextConfig, { routeManifestInjection: { exclude: (route) => route.includes('hidden') } }) ``` closes #18713
![sentry[bot]](https://avatars.githubusercontent.com/u/1396951?s=60&v=4){kind=small}
Comment on lines
+70
to
+79
| data: { | ||
| function: generationFunctionIdentifier, | ||
| }, | ||
| ); | ||
| }, | ||
| ); | ||
| }); | ||
| }); | ||
| }, | ||
| }); | ||
| } | ||
| }, | ||
| () => { | ||
| waitUntil(flushSafelyWithTimeout()); | ||
| }, |
There was a problem hiding this comment.
Bug: The isolationScope.setTransactionName() call is incorrectly placed within an error handler, so transaction names are not set for successful generation function executions.
Severity: HIGH
Suggested Fix
Move the isolationScope.setTransactionName(transactionName) call to before the handleCallbackErrors function is invoked. This will ensure the transaction name is set on the scope for both successful and failed executions, consistent with other wrapper functions.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: packages/nextjs/src/common/wrapGenerationFunctionWithSentry.ts#L70-L79
Potential issue: In `wrapGenerationFunctionWithSentry`, the call to
`isolationScope.setTransactionName()` is located inside the `onError` callback of
`handleCallbackErrors`. This means the transaction name will only be set when the
wrapped generation function (e.g., `generateMetadata`) throws an error. For all
successful executions, the transaction name will be missing in Sentry. This is a
functional regression that hinders observability by making it difficult to identify and
group transactions for successfully executed generation functions.
Did we get this right? 👍 / 👎 to inform future reviews.
Comment on lines
+49
to
+52
| isolationScope.setTransactionName(`${componentType}.${generationFunctionIdentifier} (${componentRoute})`); | ||
|
|
||
| const activeSpan = getActiveSpan(); | ||
| if (activeSpan) { | ||
| const rootSpan = getRootSpan(activeSpan); | ||
| const sentryTrace = headersDict?.['sentry-trace']; | ||
| if (sentryTrace) { | ||
| rootSpan.setAttribute(TRANSACTION_ATTR_SENTRY_TRACE_BACKFILL, sentryTrace); | ||
| if (span) { | ||
| if (isNotFoundNavigationError(error)) { |
There was a problem hiding this comment.
Bug: The transaction name is only set on failed executions of generation functions, as setTransactionName is incorrectly placed inside the onError callback.
Severity: HIGH
Suggested Fix
Move the isolationScope.setTransactionName(...) call to occur before the handleCallbackErrors function is invoked. This will ensure the transaction name is set for both successful and failed executions, restoring the behavior of the previous implementation.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: packages/nextjs/src/common/wrapGenerationFunctionWithSentry.ts#L49-L52
Potential issue: The transaction name for generation functions like `generateMetadata`
is now set exclusively within the `onError` callback of `handleCallbackErrors`. The
`onError` callback is only executed when an error is thrown. As a result, for any
successful execution of these generation functions, the transaction name is never set.
This leads to a loss of observability in Sentry, as successful operations will not be
correctly named, making them difficult to trace and monitor. Only failed executions will
have their transaction names properly recorded.
Did we get this right? 👍 / 👎 to inform future reviews.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
size-limit report 📦
|
Contributor
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
chargome
reviewed
Jan 14, 2026
CHANGELOG.md
Outdated
|
|
||
| - **feat(nextjs): Add routeManifestInjection option to exclude routes from client bundle ([#18798](https://github.com/getsentry/sentry-javascript/pull/18798))** | ||
|
|
||
| A new `routeManifestInjection` option allows you to exclude specific routes from being injected into the client bundle, helping reduce bundle size for applications with many routes. |
Member
There was a problem hiding this comment.
This is not a feature for reducing bundle size, but for excluding sensitive routes in the client bundle
Member
Author
There was a problem hiding this comment.
Great catch, I remove that second part of the sentence
JPeer264
force-pushed
the
prepare-release/10.34.0
branch
from
e85cc63 to
f9e4fc1
Compare
nicohrubec
approved these changes
Jan 14, 2026
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.