meta(changelog): Update changelog for 8.35.0 #14022
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
Fixes #13932 We have defined the type for the shared client/server types in meta-frameworks incorrectly, `init` now returns `Client | undefined` and not `void` anymore.
This PR is a pretty big change, but it should help us to make custom
OTEL support way better/easier to understand in the future.
The fundamental problem this PR is trying to change is the restriction
that we rely on our instance of `HttpInstrumentation` for
Sentry-specific (read: not span-related) things. This made it
tricky/annoying for users with a custom OTEL setup that may include
`HttpInstrumentation` to get things working, because they may
inadvertedly overwrite our instance of the instrumentation (because
there can only be a single monkey-patch per module in the regular
instrumentations), leading to hard-to-debug and often subtle problems.
This PR fixes this by splitting out the non-span related http
instrumentation code into a new, dedicated `SentryHttpInstrumentation`,
which can be run side-by-side with the OTEL instrumentation (which emits
spans, ...).
We make this work by basically implementing our own custom, minimal
`wrap` method instead of using shimmer. This way, OTEL instrumentation
cannot identify the wrapped module as wrapped, and allow to wrap it
again. While this is _slightly_ hacky and also means you cannot unwrap
the http module, we do not generally support this for the Sentry SDK
anyhow.
This new Instrumentation does two things:
1. Handles automatic forking of the isolation scope per incoming
request. By using our own code, we can actually make this much nicer, as
we do not need to retrospectively update the isolation scope anymore,
but instead we can do this properly now.
2. Emit breadcrumbs for outgoing requests.
With this change, in errors only mode you really do not need our
instance of the default `HttpInstrumentation` anymore at all, you
can/should just provide your own if you want to capture http spans in a
non-Sentry environment. However, this is sadly a bit tricky, because up
to now we forced users in this scenario to still use our Http instance
and avoid adding their own (instead we allowed users to pass their Http
instrumentation config to our Http integration). This means that if we'd
simply stop adding our http instrumentation instance when tracing is
disabled, these users would stop getting otel spans as well :/ so we
sadly can't change this without a major.
Instead, I re-introduced the `spans: false` for `httpIntegration({
spans: false })`. When this is set (which for now is opt-in, but
probably should be opt-out in v9) we will only register
SentryHttpInstrumentation, not HttpInstrumentation, thus not emitting
any spans. Users can add their own instance of HttpInstrumentation if
they care.
One semi-related thing that I noticed while looking into this is that we
incorrectly emitted node-fetch spans in errors-only mode. This
apparently sneaked in when we migrated to the new undici
instrumentation. I extracted this out into a dedicated PR too, but the
changes are in this too because tests were a bit fucked up otherwise.
On top of #13765
This also includes a bump of import-in-the-middle to 1.11.2, as this
includes a fix to properly allow double-wrapping ESM modules.
Module federation needs package version for comparison fixes #12433
It seems that `github.actor` is not necessarily the PR author, but possibly the user that merged the PR. You can see e.g. here: https://github.com/getsentry/sentry-javascript/actions/runs/11270299315/job/31340702772 how it still ran for a dependabot PR.
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #13922 Co-authored-by: mydea <[email protected]>
…3952) Updates the loader & adds tests for getsentry/sentry#78993
See #13744 for more information
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #13875 Co-authored-by: mydea <[email protected]>
…avior (#13953) Add a browser integration test that describes the current behaviour of how we update the `transaction` field in the DSC which is propagated via the `baggage` header and added to envelopes as the `trace` header.
…ssion (#13962) This fixes a bug where an older, saved session (that has a `previousSessionId`, i.e. session was recorded and expired) would cause buffered replays to not send when an error happens. This is because the session start timestamp would never update, causing our flush logic to skip sending the replay due to incorrect replay duration calculation.
Resolves: #13279 Depends on: #13840 [Sample Event](https://sentry-sdks.sentry.io/issues/5939879614/?project=5429219&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=issue-stream&sort=date&statsPeriod=1h&stream_index=0) Docs PR: getsentry/sentry-docs#11516 Adds a Pinia plugin with a feature set similar to the Redux integration. - Attaches Pinia state as an attachment to the event (`true` by default) - Provides `actionTransformer` and `stateTransformer` to the user for potentially required PII modifications. - Adds breadcrumbs for Pinia actions - Assigns Pinia state to event contexts.
…exception (#13965) Change this to be a warn level log instead of an exception (which gets captured to Sentry). Since this is an error we are throwing ourselves and it is to be expected, no need to treat as an exception. This also adds a new meta string to differentiate from an error while parsing. This means we can show a more specific error message on the frontend.
…es to breadcrumbs (#13970) Fix a bug which caused the `httpIntegration`'s `ignoreOutgoingRequests` option to not be applied to breadcrumb creation for outgoing requests. As a result, despite spans being correctly filtered by the option, breadcrumbs would still be created which contradicts the function'S JSDoc and [our docs](https://docs.sentry.io/platforms/javascript/guides/node/configuration/integrations/http/#ignoreoutgoingrequests). This patch fixes the bug by: - correctly passing in `ignoreOutgoingRequests` to `SentryHttpIntegration` (same signature as `httpIntegration`) - reconstructing the `url` and `request` parameter like in the [OpenTelemetry instrumentation](https://github.com/open-telemetry/opentelemetry-js/blob/7293e69c1e55ca62e15d0724d22605e61bd58952/experimental/packages/opentelemetry-instrumentation-http/src/http.ts#L756-L789) - adding/adjusting a regression test so that we properly test agains `ignoreOutgoingRequests` with both params. Now not just for filtered spans but also for breadcrumbs.
…n fetch instrumentation (#13907)
…ts/test-applications/cloudflare-astro (#13974)
#13983) Resolves: #13774 Fastify v5 is enabled with release: https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-fastify-v0.40.0
The E2E tests still used an `instrument` file in the `public` folder (which is not the way to setup the SDK anymore) because `import-in-the-middle/hook.mjs` was not available and threw an error. To be able to properly test the setup with `sentry.server.config.ts`, a function was added that copies the `import-in-the-middle` folder to the build output to include all files.
BREAKING CHANGE: The `--import` flag must not be added anymore. If it is still set, the server-side will be initialized twice and this leads to unexpected errors. --- First merge this: #13945 Part of this: #13943 This PR makes it the default to include a rollup plugin that wraps the server entry file with a dynamic import (`import()`). This is a replacement for the node `--import` CLI flag. If you still want to manually add the CLI flag you can use this option in the `nuxt.config.ts` file: ```js sentry: { dynamicImportForServerEntry: false, } ``` (option name is up for discussion)
With [waitUntil](https://vercel.com/docs/functions/functions-api-reference#waituntil) the lambda execution continues until all async tasks (like sending data to Sentry) are done. Timing-wise it should work like this: `span.end()` -> `waitUntil()` -> Nitro/Node `response.end()` The problem in [this PR](#13895) was that the Nitro hook `afterResponse` is called to late (after `response.end()`), so `waitUntil()` could not be added to this hook. --- Just for reference how this is done in Nitro (and h3, the underlying http framework): 1. The Nitro `afterResponse` hook is called in `onAfterResponse` https://github.com/unjs/nitro/blob/359af68d2b3d51d740cf869d0f13aec0c5e9f565/src/runtime/internal/app.ts#L71-L77 2. h3 `onAfterResponse` is called after the Node response was sent (and `onBeforeResponse` is called too early for calling `waitUntil`, as the span just starts at this point): https://github.com/unjs/h3/blob/7324eeec854eecc37422074ef9f2aec8a5e4a816/src/adapters/node/index.ts#L38-L47 - `endNodeResponse` calls `response.end()`: https://github.com/unjs/h3/blob/7324eeec854eecc37422074ef9f2aec8a5e4a816/src/adapters/node/internal/utils.ts#L58
Noticed here: #13932 (comment) we should not add comments for prereleases 😅
…13969) For replay, performance entries are captured separately, and added to the replay before we send it. Generally, this works just fine, because when we buffer, we clear the captured performance events whenever the buffer is cleared. However, when we manually start the replay, it can happen that we capture performane entries from way before we started the replay manually, which will in turn extend the timeline of the replay potentially drastically. To fix this, we now drop any performance events, when starting manually, that happened more than a second before we manually started the replay.
Removes code snippets with `--import` and adds a "Troubleshooting" section.
) Nuxt implementation for: #13993 Fixes: #13997 In Nuxt, there are 3 places to set source maps (and all need to be enabled): - `sourcemap` - `nitro.rollupConfig.output.sourcemap` - `vite.build.sourcemap` As Nuxt sets `sourcemap.client: false` ([docs here](https://nuxt.com/docs/api/nuxt-config#sourcemap)), it's not possible to determine whether this setting was set by the user or the framework. Users have to set this manually like this: ```js export default defineNuxtConfig({ sourcemap: { client: true, }, }) ``` With this PR, all source maps are set to `'hidden'` if they were undefined before and keep the setting otherwise. This is done in 3 separate functions (one for vite, rollup and nuxt) to better distinguish between the settings.
Sentry is initialized too late in development mode and tracing does not work. This is a note to inform users about that. Will be fixed in the stable version.
s1gr1d
force-pushed
the
prepare-release/8.35.0
branch
from
3811d55 to
9aa113a
Compare
chargome
requested changes
Oct 18, 2024
s1gr1d
force-pushed
the
prepare-release/8.35.0
branch
from
9aa113a to
95b3751
Compare
chargome
approved these changes
Oct 18, 2024
size-limit report 📦
|
lforst
reviewed
Oct 18, 2024
s1gr1d
force-pushed
the
prepare-release/8.35.0
branch
from
95b3751 to
c53e851
Compare
lforst
reviewed
Oct 21, 2024
lforst
approved these changes
Oct 21, 2024
s1gr1d
force-pushed
the
prepare-release/8.35.0
branch
from
c53e851 to
5ecfb70
Compare
s1gr1d
force-pushed
the
prepare-release/8.35.0
branch
from
5ecfb70 to
f4ba039
Compare
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.
Contains beta release for
@sentry/nuxt