meta: Update Changelog for 7.59.0 #8560
Merged
Conversation
This file contains 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
Adds support for new error handling utilities of Remix v2. ([ErrorBoundary](https://remix.run/docs/en/main/route/error-boundary-v2), [handleError](https://github.com/remix-run/remix/releases/tag/remix%401.17.0)) ## `ErrorBoundary` v2 Remix's `ErrorBoundary` captures all client / server / SSR errors and shows a customizable error page. In v1, to capture client-side errors we were wrapping the whole Remix application with `@sentry/react`s `ErrorBoundary` which caused inconsistencies in error pages. (See: #5762) v2 implementation does not wrap user's application with `@sentry/react`'s ErrorBoundary, instead it exports a capturing utility to be used inside the Remix application's `ErrorBoundary` function. Can be used like: ```typescript import { captureRemixErrorBoundaryError } from '@sentry/remix'; export const ErrorBoundary: V2_ErrorBoundaryComponent = () => { const error = useRouteError(); captureRemixErrorBoundaryError(error); return <div> ... </div>; }; ``` It also requires `v2_errorBoundary` [future flag](https://remix.run/docs/en/1.18.0/pages/api-development-strategy#current-future-flags) to be enabled. ## `handleError` For server-side errors apart from 'Error Responses' (thrown responses are handled in `ErrorBoundary`), this implementation exports another utility to be used in `handleError` function. The errors we capture in `handleError` also appear on `ErrorBoundary` functions but stacktraces are not available. So, we skip those errors in `captureRemixErrorBoundaryError` function. `handleError` can be instrumented as below: ```typescript export function handleError(error: unknown, { request }: DataFunctionArgs): void { if (error instanceof Error) { Sentry.captureRemixServerException(error, 'remix.server', request); } else { // Optionally Sentry.captureException(error); } ```
- Adds the `ModuleMetadata` integration that fetches metadata injected via bundler plugins and attaches is to the `module_metadata` property of every `StackFrame`.
- This can later be used in `beforeSend` or another integration to route events depending on the metadata.
- This integration is
- Exported separately from `@sentry/core` (ie. not in `Integrations`) so it doesn't get included in default bundles
- Exported separately from `@sentry/browser` so that it can be used without depending directly on core
- Uses the `beforeEnvelope` hook to strip the `module_metadata` property from stack frames
- Adds a test to ensure `module_metadata` is available in `beforeSend` and is stripped before sending
As long as our SDK and `[email protected]` aren't compatible, we need to hard-pin our NextJS integration tests to `13.4.9` to unblock our CI. We need to revert this change once we figured out 13.4.10! (Set a reminder for myself)
When an error occurs in `beforeAddRecordingEvent`, we just skip this event and log the error. Closes #8542
Apparently accessing sessionStorage in an iframe with certain permissions can result in a throw, so we try-catch this to ensure we do not produce any errors. Closes #8392
Noticed the commands are a bit off, so fixed them!
Turns out, `HTTP_TARGET` is always the relative path, even for outgoing requests, which omits the host. So we handle this specifically now here. While at it (and as I'm working a bit in this codebase), I also renamed the files from kebap-case to camelCase, to align with the rest of the codebase better - unless there was a specific reason to use that here @AbhiPrasad ? Closes #8535
As reported in #8541, our NextJS SDK currently breaks dev mode for the newest NextJS 13.4.10 version I still have absolutely no idea which of the changes in [13.4.10](https://github.com/vercel/next.js/releases/tag/v13.4.10) is causing this. However, I traced the error back and it happens as soon as our NextJS SDK package requires @sentry/webpack-plugin: * @sentry/nextjs calls `require('@sentry/webpack-plugin')` * @sentry/webpack-plugin calls `const { RawSource } = require('webpack-sources');` * For _whatever_ reason, NextJS can't require `webpack-sources` and throws Since we don't enable our Webpack plugin [in dev mode](https://github.com/getsentry/sentry-javascript/blob/723f851f358b75cd39da353804c51ff27ebb0c11/packages/nextjs/src/config/webpack.ts#L305) anyway, one way to get rid of this error is to only require it if we're _not_ in dev mode. This hotfix therefore moves the top-level require of `@sentry/webpack-plugin` to a dynamic require. This isn't a great solution and honestly quite ugly but if it unblocks users for now I'd say we merge it. I think we should definitely revisit this though once we know more about why NextJS suddenly isn't able to import `webpack-sources`. closes #8541
size-limit report 📦
|
Protocols are from https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids which don't exactly match the OSI. We can consider adding a lookup table later if people are finding this insufficient. Co-authored-by: Abhijeet Prasad <[email protected]>
…8559) The multiplexed transport can already route events to different or multiple DSNs but we also need to be able to route to specific releases too. In a page with micro-frontends, it's possible (and probably even quite common) to be using the same dependency multiple times but different versions (ie. different releases). Depending on where an error occurs we might want to send an event to `[email protected]` or `[email protected]` at the same DSN. This PR: - Adds a private `makeOverrideReleaseTransport` which can used to wrap a transport and override the release on all events - Modifies `makeMultiplexedTransport` so it now creates a transport for each unique dsn/release pair - And uses `makeOverrideReleaseTransport` whenever a release is returned from the callback
|
gonna merge in #8563 and then rebase this release to include it |
Co-authored-by: Abhijeet Prasad <[email protected]>
AbhiPrasad
force-pushed
the
prepare-release/7.59.0
branch
from
f079f71
to
0c07815
Compare
AbhiPrasad
force-pushed
the
prepare-release/7.59.0
branch
from
0c07815
to
5eb0bdd
Compare
AbhiPrasad
approved these changes
Jul 17, 2023
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.