meta(changelog): Update changelog for 9.39.0 #17020
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
…ob (#16930) Looks like node-core integration tests ran in our Node unit test job matrix. This is because the package is not excluded from the `test:pr` top-level NPM script.
resolves #16913 --------- Co-authored-by: Andrei Borza <[email protected]>
resolves https://linear.app/getsentry/issue/JS-663 Categorizing the attributes this way helps us differentiate between the ai attributes added by vercel compared to the otel semantic conventions.
…signment on web vital spans (#16893) Our standalone web vital spans need to include the span id of the `pageload` span s.t. we can correctly assign the web vital value to the respective pageload span in the Sentry backend. In the previous implementation, we'd simply wait for a tick after tracking the web vitals, get the active root span and take its spanId if it was a pageload span. However, this relies on the assumption that the pageload span is indeed started immediately. By default this happens but users can always deactivate default behaviour and call `startBrowserTracingPageloadSpan` whenever they want (for example, in a custom `browserTracingIntegration`). Furthermore, this "wait for a tick" logic always bugged me and was only done because `getClient()` would not yet return the already initialized client. This change now makes the pageload spanId retrieval more robust by - adding and listening to a new SDK lifecycle hook: `afterStartPageloadSpan`. This callback fires as soon as the pageload span is actually started and available. - passing the `client` from the `browserTracingIntegration`'s `setup` hook into the web vital listening function so that we can remove the `setTimeout(_, 0)` logic.
resolves #16940 Migrates `@sentry/react` to use the `debug` utility instead of `logger` from `@sentry/core`. This change aligns with the ongoing effort to streamline logging utilities within the SDK, moving towards a more focused `debug` function. --- Before submitting a pull request, please take a look at our [Contributing](https://github.com/getsentry/sentry-javascript/blob/master/CONTRIBUTING.md) guidelines and verify: - [x] If you've added code that should be tested, please add tests. - [x] Ensure your code lints and the test suite passes (`yarn lint`) & (`yarn test`). --------- Co-authored-by: Cursor Agent <[email protected]>
This is pretty small, but apparently `Object.assign()` also counts as side effect. Part of #16846
) Instead of having a side effect of writing on the GLOBAL_OBJ, we can use a global singleton instead. Part of #16846
…16928) When we we start and send a web vital standalone span while an idlespan (e.g. pageload) was still running, we'd restart the idle span's child span timeout (i.e. prolong its duration potentially). Is is unintended because by definition the standalone span should not be associated with a potentially ongoing idle span and its tree. This can happen, for example when users hide the page while the pageload span is still active, causing web vitals to be reported.
Link "homepage" on https://www.npmjs.com/package/@sentry/aws-serverless links to a 404 page, as it targets the old `serverless` URL. Is: https://github.com/getsentry/sentry-javascript/tree/master/packages/serverless Should be: https://github.com/getsentry/sentry-javascript/tree/master/packages/aws-serverless This is the fix. Not sure about the commit message, feel free to pick this up and adjust. This PR is similar to the one for GCP: #14411
resolves #16920 This will prevent recursive calls to `beforeSendLog` when using console logging instrumentation which will cause crashes.
resolves #16945 Co-authored-by: Cursor Agent <[email protected]>
To ensure we get the correct node version etc.
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #16979 Co-authored-by: andreiborza <[email protected]>
…#16919) This PR updates `@sentry-internal/node-native-stacktrace` to v0.2.0 which supports disabling last time tracking per thread. The integration needed quite a few changes and I split it into more functions but all the tests still pass! This PR then adds `pauseEventLoopBlockDetection()`, `restartEventLoopBlockDetection()` which can be used to pause and restart detection and `disableBlockDetectionForCallback` which can be used like this: ```ts import { disableBlockDetectionForCallback } from '@sentry/node-native'; disableBlockDetectionForCallback(() => { someLongBlockingFn(); }); ```
resolves #16937 Also reaches into `packages/browser-utils/src/networkUtils.ts` to make a quick change. Please review `packages/replay-internal/src/util/logger.ts` carefully.
In addition to 404, we now also drop 401, 402, 403 and 3xx (e.g. 301 MOVED_PERMANTENTLY) spans by default. These are usually not helpful. Noticed this in some react-router E2E test where 301 spans were messing with the test, but these should not even be captured really. --------- Co-authored-by: Andrei Borza <[email protected]>
Allows rollup minor and patch versions above 4.35.0 so that rollup dependencies specifying a similar version range can be better deduped.
Instead, we can just check the required things directly on the span. This is likely a bit more expensive than checking a map, but I would not assume this operation should be happening too excessively, so IMHO this should be fine. This is also part of #16846 @aliu39 do you see any problems with this change?
…16984) This updates the browser tracing implementation in react router to ensure that we always have parametrized routes. In the previous implementation, if the parametrized route was the same as the "initial" one, we would just do nothing and the source remains URL. We would also not set the origin of the spans. this is not correct, because we actually ensured this is parametrized (there are simply no parameters in, but still!), so the source should still be `route` in this case.
This adds a new attribute to spans that we send from the Node SDK because their parent span was already sent. This can be used by us or customers to debug why certain things show up as transactions/root spans in product. We could possibly also use this in the trace view to give users helpful pointers.
While adding the SDK to the release-registry I noticed that we never apply the correct metadata to node-core. 64d056a failing tests show the node-core SDK getting incorrect `sentry.javascript.node` metadata (from `NodeClient`) 88a975a applies correct metadata to both SDKs I was debating changing the underlying `NodeClient` to not automatically set `sentry.javascript.node` but wasn't sure of the implications so decided not to.
…16986) This updates react router http.server handling to ensure: * That we always have a correct route/url source * Streamlines how we get rid of the weird `*` transaction name by just using `processEvent` in the integration. This means we now always add the server integration, it just does less in non-matching node versions. * Ensure we always have a good span origin * Ensure the name of the spans is consistent with the target (e.g. containing the .data suffix) - we can revisit this later but for now this is consistent I'd say.
…7016) Counter-part in sentry-release-registry: getsentry/sentry-release-registry#200
resolves #16942 --------- Co-authored-by: Cursor Agent <[email protected]>
resolves #16941 --------- Co-authored-by: Cursor Agent <[email protected]>
resolves #16938
resolves #16944
andreiborza
approved these changes
Jul 15, 2025
size-limit report 📦
|
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.