Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 11 commits
- 65 files changed
- 8 contributors
Commits on Mar 20, 2025
-
node: implement new continuous profiling API spec (#15635)
Implements #15636 (comment) and deprecates the old Sentry.profiler.start and Sentry.profiler.stop calls --------- Co-authored-by: Sigrid Huemer <32902192+s1gr1d@users.noreply.github.com>
-
perf(core): Add short-circuits to
eventFiltersintegration (#15752)Ref: #15725 - Only does the options merging once - Adds short circuiting for event types to avoid doing things multiple times/unnecessarily --------- Co-authored-by: Francesco Gringl-Novy <francesco.novy@sentry.io>
-
feat(react): Export captureReactException method (#15746)
This PR exports the `captureReactException` method from the React package, making it available as a public API. Additionally, it refactors the implementation to use `withScope` instead of directly passing context to `captureException`. This was done so that the arguments to `captureReactException` better align to `captureException`. Users can now directly access and use this method in their applications: ```javascript import * as Sentry from '@sentry/react'; class ErrorBoundary extends React.Component { componentDidCatch(error, info) { Sentry.captureReactException(error, info); } render() { return this.props.children; } } ``` The reason why `captureReactException` is named as such and not `captureReactErrorBoundaryException` is because it can be used in other scenarios as well, like with the new React 19 error APIs. Therefore it was generalized to just be `captureReactException`. -
Merge pull request #15756 from getsentry/master
[Gitflow] Merge master into develop
-
profiling: add platform to chunk envelope (#15758)
We need to send the platform as part of envelope headers as this is the item that relay is checking to manage rate limiting. We only care about backend (node) and in the future frontend. @AbhiPrasad please correct me here to use the correct convention, would `javascript.node` be more appropriate? The only requirement really is to have all nodejs platform types be of a single platform type, so we dont need to maintain the ever growing list in relay
There are no files selected for viewing