meta(changelog): Update changelog for 9.37.0 #16892
Merged
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
…16839) Closes #16837 This should not break anything, I actually added a test to verify injecting this works as expected. We now simply console.warn when some runtime config is passed in the astro integration. Also, no more type completion exists for these, but they are still accepted via `Record<string, unknown>`.
…16841) Previously, most of the OTEL dependencies have been `devDependencies` of the vercel-edge package. This PR fixes this by properly defining the dependencies we have. NOTE: This was not per se incorrect, just not really necessary - we used to inline all of these dependencies into the vercel-edge SDK. Only the `@opentelemetry/sdk-trace-base` dependency remains a devDependency, which means it is bundled in. Without this, edge routes somehow fail on next 13 :/
This just bumps the underlying transitive dependency on nitropack, which apparently changes some type imports. Extracted out of #16751
…equestHandler` (#16852) Add a `captureErrors` option to the `wrapRequestHandler` options from `@sentry/cloudflare`. While by default, the wrapper should capture exceptions (for example, when it's used in pure CF worker functions), it shouldn't do that when it's used in higher-level SDKs, like SvelteKit. There, we want our other error capturing implementations to do the job.
…flare (#16853) We want to avoid capturing errors too early and too generally via the `initCloudflareSentryHandle` request handler. Internally, this handler uses a wrapper from `@sentry/cloudflare` to capture errors but prior to #16852 it captured everything that was thrown. This included thrown `redirect()` objects from SvelteKit which serve as control flow mechanisms but should not be captured as errors. This patch opts out of capturing errors in the Cloudflare wrapper. Instead, we rely on our already existing error capturing mechanisms in SvelteKit, which already ignore `redirect()` and a few other error classes.
This adds explicit peer dependecies in the solidstart package. Those are dev dependencies only. Importantly, that seems to bump some things that result in slightly different types we need to adjust to. Extracted out of #16751
This adds missing peer dependencies that yarn complains about. Nothing should change, fundamentally. Extracted this out of #16744
Closes #15286 This PR adds a new option to `browserTracingIntegration`, `detectRedirects`, which is enabled by default. If this is enabled, the integration will try to detect if a navigation is actually a redirect based on a simple heuristic, and in this case, will not end the ongoing pageload/navigation, but instead let it run and create a `navigation.redirect` zero-duration span instead. An example trace for this would be: https://sentry-sdks.sentry.io/explore/discover/trace/95280de69dc844448d39de7458eab527/?dataset=transactions&eventId=8a1150fd1dc846e4ac8420ccf03ad0ee&field=title&field=project&field=user.display&field=timestamp&name=All%20Errors&project=4504956726345728&query=&queryDataset=transaction-like&sort=-timestamp&source=discover&statsPeriod=5m×tamp=1747646096&yAxis=count%28%29  Where the respective index route that triggered this has this code: ```js setTimeout(() => { window.history.pushState({}, "", "/test-sub-page"); fetch('https://example.com') }, 100); ``` The used heuristic is: * If the ongoing pageload/navigation was started less than 300ms ago... * ... and no click has happened in this time... * ... then we consider the navigation a redirect this limit was chosen somewhat arbitrarily, open for other suggestions too. While this logic will not be 100% bullet proof, it should be reliable enough and likely better than what we have today. Users can opt-out of this logic via `browserTracingIntegration({ detectRedirects: false })`, if needed. --------- Co-authored-by: Sigrid Huemer <[email protected]>
Adds route parametrization to SSR server routes. The parametrized route data is gathered during build time and saved in a virtual file (added with [`addTemplate`](https://nuxt.com/docs/4.x/api/kit/templates#creating-a-virtual-file-for-runtime-plugin)) which can hand-over the data to be accessed during runtime. The `nuxt-3-min` test (Nuxt 3.7) shows that the route parametrization does not work yet with this version. From Nuxt 3.9 onwards, it works. This is fine, as most people are on a more recent version anyways. part of #16684
And also remove the unused opentelemetry-instrumentation-remix Not sure if there are others we want to include 🤔
To not have the need of manually adding another package when wanting to use the Cloudflare SDK, we always add it. This is already the case in the SvelteKit SDK.
Updates this so we get newest browsers etc. Also aligns version everywhere again.
This change adds a new `beforeStartNavigationSpan` lifecycle hook that gets triggered directly before the `startNavigationSpan` hook by the `startBrowserTracingNavigationSpan` helper function. The reason we need this is because we have logic for standalone CLS and LCP spans that needs to run _before_ we start preparing any work that's executed at the `startNavigationSpan` hook: - `beforeStartNavigationSpan`: send standalone span with the pageload trace id (i.e. the currently still active trace id on the propagation context - `startNavigationSpan`: first recycles the propagation context, then starts the new span This change does not yet include switching over LCP and CLS collection to the new hook (coming in a follow-up commit)
…eload span (#16864) Fix a bug in standalone web vital spans where, if they were sent because of a navigation, they would incorrectly be added to the `navigation` span's trace instead of the initial `pageload` span's trace. This surfaced while dogfooding these spans on sentry and inspecting them in the EAP traceview. To fix this, I added a lifecycle hook in #16863 that triggers right before we start preparing the navigation span and hence, right before we recycle the propagation context to the new traceId. This patch now makes use of the new hook for CLS and LCP spans and it also makes the integration tests stricter to check for the correct trace ids.
Test follow-up for this PR: #16843 Re-organizes the unit tests a bit to be less repetitive with default data that is aligned to real-world examples. --- Adds unit tests for cases mentioned [here](#16843 (comment)): - differentiate dynamic vs static route on the same path (`users/:id` vs `users/settings`) - cases for catch-all routes
size-limit report 📦
|
s1gr1d
force-pushed
the
prepare-release/9.37.0
branch
from
cbc0e92 to
e2ca660
Compare
andreiborza
reviewed
Jul 10, 2025
| ### Other Changes | ||
|
|
||
| - feat(astro): Deprecate passing runtime config to astro integration ([#16839](https://github.com/getsentry/sentry-javascript/pull/16839)) | ||
| - feat(browser): Add `beforeStartNavigationSpan` lifecycle hook ([#16863](https://github.com/getsentry/sentry-javascript/pull/16863)) |
There was a problem hiding this comment.
l: Maybe we should highlight this as an important change and add a snippet for how to use it, wdyt?
There was a problem hiding this comment.
@Lms24 I am not sure here but I think those hooks are mainly meant for our SDK internally?
There was a problem hiding this comment.
yes, they're internally mostly. no need for an important change
s1gr1d
commented
Jul 10, 2025
Comment on lines
+27
to
+29
| - docs(nextjs): Update `deleteSourcemapsAfterUpload` jsdoc default value ([#16867](https://github.com/getsentry/sentry-javascript/pull/16867)) | ||
|
|
||
| Work in this release was contributed by @zachkirsch. Thank you for your contribution! |
There was a problem hiding this comment.
Usually, we don't list docs PRs but this was added by an external contribution so I left it here.
There was a problem hiding this comment.
I think we can remove the entry but keep the attribution, but no strong opinion
andreiborza
approved these changes
Jul 10, 2025
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.