meta(changelog): Update changelog for 10.23.0 #18090
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
During the release I figured that most of the times you might work on features/bugfixes. In that case the current release process this scenario isn't specified and who knows what it might or might not do. I added point 1. and 9. where we ask Cursor to save the changes (1) and go back to the state it was before (9). This would make the release process more complete. --------- Co-authored-by: Charly Gomez <charly.gomez@sentry.io>
[Gitflow] Merge master into develop
) While exploring the Timeout Warning feature in `Sentry.wrapHandler`, I fount a type in the function name. It seems `setupTimeoutWarning` was intended name, so I've corrected it accordingly. ## Changes - Renamed `setupTimeoutWatning` → `setupTimeoutWarning` - Updated all 3 call sites to use the corrected function name ## Checklist - [x] Code lints successfully (`yarn lint`) - [x] No new tests required (typo fix only, no functional changes)
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #18031 Co-authored-by: andreiborza <168741329+andreiborza@users.noreply.github.com>
The flakey tests in nuxt-4 pointed out that we have a race condition where a middleware error can bubble up as an H3 event error, which wraps the original error we caught. This means the [`checkOrSetAlreadyCaught`](https://github.com/getsentry/sentry-javascript/blob/749638766641b552e1193353c3f0430cf970787d/packages/core/src/utils/misc.ts#L212-L232) won't actually detect it since it doesn't check the [`.cause` property](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause). I added the logic needed for that for the Nuxt SDK but feels like this may come up later if it hadn't already. Note that this does not affect the spans created, just the mechanism of the caught error, the spans would still be marked correctly as errored.
… SDKs (#17929) As a follow-up of an incident, SDKs were asked to send a `user-agent` Http header to determine by just looking at incoming request headers which SDK the request is coming from. See [develop specification](https://develop.sentry.dev/sdk/overview/#user-agent). This PR makes the following changes to sending user agent HTTP headers with envelope requests made by the transport: - Send `user-agent` in all server-runtime SDKs - Extract the `headers` option from individual transport options to `BaseTransportOptions`. This allows us to type-safely add the user agent header to the SDKs transport options which is the easiest way to pass a header to the transport without having to modify or extend any of the existing transport APIs. I checked and every transport implementation we currently export exposed a `headers` option anyway, so this just unifies it. Given this is an optional property, custom transport implementations extending `BaseTransportOptions` won't break either. The problem here is only that they might not actually support this option which all things considered I think is fine. If reviewers have different opinions, I'm happy to revisit this. - Unit and integration/e2e tests for node and cloudflare
changelog: https://github.com/dumbmatter/fakeIndexedDB/blob/master/CHANGELOG.md removes a structured clone polyfill, which is fine because we are node 18+ in the SDK. This helps reduce dep count in `yarn.lock`.
This PR fixes a case where we [correctly] tag an error event w/ replay id, but something occurs where the replay event does not end up being flushed. This means the existing session is still in a buffered state, and will keep its session id until a new error event is sampled and a replay is created. When this does happen, we can have a replay with a super long duration (e.g. the time between the two error replays). We now update the session immediately when we tag an error event w/ replay id so that if the replay event does not successfully flush, the session will respect its expiration date.
…hanges (#18033) This test displays the current behavior of getting the element target name for INP when the DOM changes after clicking on a navigation link. When the DOM changes after clicking on an element, the element name from before the navigation is not captured: ```js description: '<unknown>', // FIXME: currently unable to get the target name when element is removed from DOM ```
#17909) This PR refactors almost all occurances of our SDK setting a span status of `unknown_error` to setting `internal_error` instead. #17814 explains why we do this. I left a few selected occurances of `unknown_error` where I think it's fine to not change them. Worth noting, Relay already converts `unknown_error` to `internal_error`, so this is rather a "cleanup" and only has impact on self-hosted Sentry versions for now. closes #17814
The SDK should only truncate when really necessary on the client. Therefore, the default value of 250 is removed. Part of #17389
Nitro `2.10` was failing our tests due to 500 errors, logs didn't show anything about what was failing but removing the override which then makes it use nitro `2.12.9` makes the tests pass again. I tried almost all releases from `2.10` to `2.12.8` and they all fail the tests due to timeouts, so only the very last release is the one working, I think we might have a deep dependency causing this, but for now this works for our tests. Nitropack shouldn't even be part of user dependencies as it is determined by the Nuxt version accepted range.
Fixes ERR_REQUIRE_ESM error in React Router 7 E2E tests by pinning p-map to v4 which supports CommonJS, resolving incompatibility with @react-router/dev v7.5+ that uses require() instead of dynamic import(). React Router should fix this upstream, this is a workaround now.
When running tests, sometimes it is useful to target specific tests or to pass flags like `--debug` to the playwright test command. With this PR you can do: ``` yarn test:run app-name -g "captures error thrown on click" --debug ```
Fixes interaction elements showing up as `<unknown>` in case they get removed from the DOM. The implementation adds global listeners to listen for interaction events and store the most recent 50 events in an LRU-like cache then matches that with the performance entry timestamp.
…18072) Looks like our Vue documentation for how to [dynamically attach an errorHandler](https://docs.sentry.io/platforms/javascript/guides/vue/features/multiple-apps/#dynamic-initialization) to a Vue app advertised that `attachErrorHandler` can be called without having to specify options. Intuitively, this makes sense to me since the only option we actually read is `attachProps`. We can instead default this to true (just like in the main Vue init option) and make the `options` parameter optional. For v11, we should consider gating prop data attachment behind `sendDefaultPii`. I added a TODO to the code. closes #18060
This is fixing type safety for Cloudflare handlers. With that change the tests have the correct types and vitest can run through 🚀
It seems that in some cases where an `environment` in Vite is set to something other than `node` or `browser`, it won't be able to figure out the correct import paths. This PR ensures that when Vite (or other tools) can't determine the environment from "browser" or "node" conditions alone, then it falls back to the server bundle similar to what we do in Next.js. In the issue's case it was set to `nuxt` or rather `vitest-environment-nuxt` which doesn't seem like a pattern to account for. closes #18070
…ration (#18054) Previously, only synchronous errors thrown in web workers would bubble up and be captured. Unhandled promise rejections within workers would fail silently since they don't propagate to the parent thread automatically. This enhancement ensures complete error coverage for web worker code.
This fixes an issue when we are wrapping Next.js 16+ proxy.ts files, the webpack loader was exporting both middleware and proxy named exports, causing Next.js to potentially treat proxy files incorrectly as middleware files. closes #18001
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
|
|
||
| // Once this session ends, we do not want to refresh it | ||
| if (this.session) { | ||
| this.session.dirty = false; |
There was a problem hiding this comment.
Bug: The dirty flag is prematurely reset to false before flush completion, removing protection against incorrect session.started resets.
Severity: HIGH | Confidence: 0.95
🔍 Detailed Analysis
The dirty flag is set to false at packages/replay-internal/src/replay.ts:609 before a flush operation completes. This flag is intended to prevent session.started from being reset to the earliest buffered event, a critical protection if the flush fails or encounters errors. Clearing it prematurely removes this protection, allowing session.started to be incorrectly adjusted if new recording events are processed, potentially extending the session's lifetime beyond its intended duration.
💡 Suggested Fix
Clear the session.dirty flag only after a successful flush operation has completed, ensuring the protection against premature session.started resets is maintained.
🤖 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/replay-internal/src/replay.ts#L609
Potential issue: The `dirty` flag is set to `false` at
`packages/replay-internal/src/replay.ts:609` before a flush operation completes. This
flag is intended to prevent `session.started` from being reset to the earliest buffered
event, a critical protection if the flush fails or encounters errors. Clearing it
prematurely removes this protection, allowing `session.started` to be incorrectly
adjusted if new recording events are processed, potentially extending the session's
lifetime beyond its intended duration.
Did we get this right? 👍 / 👎 to inform future reviews.
size-limit report 📦
|
andreiborza
requested changes
Nov 4, 2025
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
force-pushed
the
prepare-release/10.23.0
branch
from
1d40e67 to
ddaec08
Compare
andreiborza
approved these changes
Nov 4, 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.