meta(changelog): Update changelog for 9.10.0 #15867
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
When static builds are enabled, Sentry should not change webpack configuration for the server/edge runtime as there is no server. closes #12420
Sometimes, the build fails because of this error: ` ERROR Cannot set
property options of #<Object> which has only a getter `
As `nuxt.options` are always defined anyway (it's also not optional in
the `Nuxt` type), we can safely delete the assertion to `{}` which
causes the error to dissapear.
We probably don't need this!
We can instead of `??` to get the same outcome.
Another place to get rid of this, this is serialized afterwards and this should not really matter!
This test now failed twice in a row for me and I've seen it fail in countless PRs. Skipping it for now but we should prioritize #15579 to eventually unflake and unskip them again.
…s/test-applications/nuxt-3-min (#15744)
Reducing version for E2E test which tests the minimum supported version for Nuxt. Was bumped here: #15744
[Gitflow] Merge master into develop
While trying to debug #15707 I added a new integration test. Figured we should merge this in for now.
…sts/test-applications/nextjs-app-dir (#15799)
ref #15526 Continuing off the work from #15763, this PR adds the logging public API to the Node SDK. It also adds a basic weight-based flushing strategy to the SDK that is in the server-runtime client. The main file added was `log.ts`. In that file I've added logger methods for `trace`, `debug`, `info`, `warn`, `error`, `fatal` (the log severity levels) as well as an internal capture log helper all these methods call. Usage: ```js import * as Sentry from "@sentry/node"; Sentry.init({ dsn: "your-dsn-here", _experiments: { enableLogs: true // This is required to use the logging features } }); // Trace level (lowest severity) Sentry.logger.trace("This is a trace message", { userId: 123 }); // Debug level Sentry.logger.debug("This is a debug message", { component: "UserProfile" }); // Info level Sentry.logger.info("User %s logged in successfully", [123]); // Warning level Sentry.logger.warn("API response was slow", { responseTime: 2500 }); // Error level Sentry.logger.error("Failed to load user %s data", [123], { errorCode: 404 }); // Critical level Sentry.logger.critical("Database connection failed", { dbHost: "primary-db" }); // Fatal level (highest severity) Sentry.logger.fatal("Application is shutting down unexpectedly", { memory: "exhausted" }); ```
…ically detect possible connectivity issues (#15821) Resolves #15780 Adds a function `diagnoseSdkConnectivity` that will resolve to various "error codes" for possible reasons why events might not land in Sentry. Originally I wanted to add an API to detect ad blockers so we can show a notification in the example pages that the wizard creates. Then I quickly thought of a different case why the SDK might not send data so I extended the API to also detect if the SDK wasn't initialized yet. We can extend this function at any point if we come up with more cases.
While working on #15767 I ran into a `parseUrl` function defined in `packages/browser-utils/src/instrument/xhr.ts`. This usage is fine, but was a bit confusing, so I renamed the method and expanded the docstring. I also expanded the types a little bit.
ref #15526 Adds support for `beforeSendLog`, currently in the `_experiments` options namespace. While adding `beforeSendLog`, I noticed the `beforeCaptureLog` was not placed correctly. This PR also fixes that, and introduces a `afterCaptureLog` that runs in the capturing lifecycle properly.
ref #15526 This adds support for parameterizing logs via the existing `ParameterizedString` type and `parameterize` function exported from the SDK. This works for all usages of the logger, so browser and Node.js. Usage: ```js Sentry.logger.info(Sentry.logger.fmt`User ${user} updated profile picture`, { userId: 'user-123', imageSize: '2.5MB', timestamp: Date.now() }); ``` `fmt` is an alias to `Sentry.parameterize` that is exported from the `logger` namespace. To support this change, I changed the typing of `ParameterizedString` to accept `unknown[]` for `__sentry_template_values__`. This is broadening the type, so should not be a breaking change. [`logentry.params`](https://github.com/getsentry/relay/blob/a91f0c92860f88789ad6092ef5b1062aa3e34b80/relay-event-schema/src/protocol/logentry.rs#L51C27-L51C32) should accept all kinds of values, relay handles formatting them correctly.
This replaces usage of `SentryError` for promise buffer control flow. Instead, we can use a symbol and just check this directly, we do not even care about the message here. ref #15725 (comment)
This removes the last remaining usages of `dropUndefinedKeys` in the SDK. It also deprecates the export from `@sentry/core` for future removal.
#15823) This PR replaces our usage of `SentryError` for control flow in our event processing. Instead, we now throw either an `InternalError` or `DoNotSendEventError` (which are just POJOs with a symbol, without a stackframe). These two also allow us to differentiate between these two use cases, which so far have been kind of combined via the log level, but are really different things - one is "expected"/configured by a user, the other is unexpected and more of a warning. I also removed the handling for `SentryError` from inbound filters, as this should then become unused. This also deprecates `SentryError`, it is no longer used and we can eventually remove it. ref #15725 (comment)
This isn't part of the spec, and will break ingestion if we allow things to be sent.
Co-authored-by: Abhijeet Prasad <[email protected]>
…5802) Related to #15725 (comment), this PR is an idea to avoid registering `on('spanStart')` hooks for all the node libraries that do not have proper hooks, unless they are used. Today, for OTEL instrumentation that does not provide span hooks, we fall back to `client.on('spanStart')` to enhance/mutate spans emitted by the instrumentation. This PR improved this by only registering the `spanStart` client hook if we detect that the OTEL instrumentation is actually wrapping something. This avoids us calling a bunch of span callbacks each time a span is started, when it is not even needed. For this, a new `instrumentWhenWrapped` utility is added which can be passed an instrumentation. This works by monkey-patching `_wrap` on the instrumentation, and ensuring a callback is only called conditionally. Note: For some (e.g. connect, fastify) we register `spanStart` in the error handler, which is even better, so there we do not need this logic.
We had this logic in the console instrumentation before but it probably makes sense to truncate all breadcrumbs to some degree for memory consumption reasons. Acts as prework for #15818 because if we don't truncate error messages they will end up as very big strings in breadcrumbs.
Related to #15725 (comment) When a span is not a root span, we do not need to do sampling work for it. By reordering stuff in the `shouldSample` function, we should be able to save a bunch of operations for the vast majority of (non-root) spans. I _think_ this should be just fine!
AbhiPrasad
requested review from
lforst and
s1gr1d
and removed request for
a team
lforst
approved these changes
Mar 27, 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.
We need logs to go out, but also resolves #15725