-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
meta(changelog): Update changelog for 10.6.0 #17461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
+3,421
−588
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
Removes the beta notice from the readme. I also changed some logs as it's actually possible to enable tracing during dev mode - thankfully, the command prints you the correct path to the Sentry server config 🙌
Extracted out of #17371 I noticed that we were not fully consistent in instrumentation IDs for integrations that have multiple instrumentation. The intent is that users can provide the _integration name_ (e.g. `Http`) and it will preload all http instrumentation. To achieve this, I adjusted the preload filter code to look for exact matches as well as `startsWith(`${name}.id`)`. I also adjusted the test to be more declarative and mock/reset stuff properly (this lead to issues in the linked PR, and should generally be a bit cleaner). I also updated all instrumentation IDs to follow this pattern. We should be mindful of following this with new instrumentation we add.
…17406) The test relied on `flush` and if the network functionality of CI does not work 100%, this test produces a timeout and fails.
As Astro currently mixes build-time and runtime options, the `release` option was omitted from the type. It's only possible to set this option with the `unstable_sentryVitePluginOptions` :( Closes #17067
This PR introduces the scaffolding for Sentry’s tracing integration with [Hono](https://hono.dev/) by adding interface-only implementations and wiring needed to verify the overall approach before filling in the tracing logic. ## Summary - Adds a new Hono Instrumentation (OpenTelemetry-based) which patches Hono route and middleware APIs. - Provides a honoIntegration exported via defineIntegration, plus an instrumentHono guard using generateInstrumentOnce. - Introduces minimal, vendored Hono types required for patching, and enums for consistent attribute naming. ## Intent & scope - Implemented interfaces only to validate the design direction. The goal is to confirm the wrapping points, attribute schema, and initialization flow before we add any span creation, context propagation, or attribute setting. - If this approach looks good, the next step is to ship a patch that implements the route handler tracing. That follow-up will include span start/finish, setting hono.type/hono.name, request path/method extraction, and trace context propagation. - No tests added in this PR because it only introduces the interface and structure. Tests will land together with the first functional instrumentation patch. ## Rationale There is an existing Hono OTel package ([@hono/otel](https://www.npmjs.com/package/@hono/otel)), but it currently lacks several features we need for a robust Sentry integration—especially middleware instrumentation and Sentry-specific integration points (e.g., seamless correlation with Sentry transactions/spans and future Sentry error handler wiring). Given these gaps, we’re proceeding with an in-repo implementation tailored for Sentry’s needs. ## Related Issue #15260
…es file (#17448) To test our firebase instrumentation, we spin up a firebase emulator with firestore rules. Looks like by default, the generated rules file was set to only allow general data access for 30 days. This caused CI to suddenly fail from Aug 17 onwards (and went unnoticed until today due to Hackweek). Since this is just us running the emulator in a CI job, I think it's okay to allow access unconditionally. Not sure though, so happy to think of something else if reviewers have concerns.
…`registerWebWorker` (#17447) Changes the type from `WebWorker` to `DedicatedWorkerGlobalScope`*. Other worker types don't support `postMessage`, so this type correctly scopes the API to its intended use (i.e. in dedicated workers).
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #17366 Co-authored-by: s1gr1d <[email protected]>
This allows code-less setup for Lambda functions running in ESM (and thus the aws-serverless SDK in general) by vendoring the OpenTelemetry AwsLambda instrumentation and wrapping the patched handler with Sentry's `wrapHandler`.
… v5 (#17395) Main changes are: 1. Instrument root `invoke_agent` span: This addresses that transaction event.spans only includes child spans, ensuring proper correlation beyond just children. 2. Refactor `vercelai` integration layout in core: Restructured the vercelai folder to mirror our other AI agent integrations (split constants/utils/index) for clarity and easier maintenance. 3. Link errors in Vercel AI v5 (metadata-based): Added support to capture and link tool errors that are returned as result metadata (not thrown). We correlate tool-call IDs to spans and set the trace/span context when capturing the error, so errors are attached to the right tool-call/trace even without a thrown exception. 4. Added tests to test vercel ai v5
This PR adds official support for instrumenting Anthropic AI SDK calls in Node with Sentry tracing, following OpenTelemetry semantic conventions for Generative AI. We instrument the following Anthropic AI SDK methods: - messages.create - messages.countTokens - models.get - models.retrieve - completions.create Supported in: - Node.js (ESM and CJS) - Will be added to cloudflare workers and vercel edge functions exports. The anthropicAIIntegration() accepts the following options: ``` // The integration respects your sendDefaultPii client option interface AnthropicAiOptions { recordInputs?: boolean; // Whether to record prompt messages recordOutputs?: boolean; // Whether to record response text } ```
…ntryRequestUrl` (#17393) This PR makes a change to our `isSentryRequestUrl` utility which is used in various parts of the SDKs. The function checks both, the DSN as well as the `tunnel` option to determine if a request URL is a URL to Sentry. I would argue, we should only return `true` for requests to Sentry's ingest endpoint. For example, if users make regular requests to the Sentry API from within their app that uses a Sentry SDK, we should not special case that request. Therefore, this PR makes the check for the request URL more specific: - If `tunnel` is not provided, return `true` iff the the url includes the host of the DSN AND if it includes the `sentry_key` query param. This param is mandatory to be sent along, as it's equal to the [public key of the DSN ](https://develop.sentry.dev/sdk/overview/#parsing-the-dsn). - If `tunnel` is provided, the check was already specific enough because the request URL has to match _exactly_ the configured tunnel URL. While writing this, I realized there are still a bunch of edge cases here that we probably also should fix but for now, let's keep things atomic. closes #17385 (^ very likely. We didn't repro this specifically but the `httpClientIntegration` bails out exactly if it hits the `isSentryRequestUrl` check)
…tests/test-applications/astro-4 (#17434) Bumps [astro](https://github.com/withastro/astro/tree/HEAD/packages/astro) from 4.16.18 to 4.16.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/withastro/astro/releases">astro's releases</a>.</em></p> <blockquote> <h2>[email protected]</h2> <h3>Patch Changes</h3> <ul> <li><a href="https://redirect.github.com/withastro/astro/pull/14241">#14241</a> <a href="https://github.com/withastro/astro/commit/760acc86f535a48a6f5195cdc53dfc72b0dc6053"><code>760acc8</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Fixes an issue where remote paths weren't correctly computed when generating assets</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/withastro/astro/blob/[email protected]/packages/astro/CHANGELOG.md">astro's changelog</a>.</em></p> <blockquote> <h2>4.16.19</h2> <h3>Patch Changes</h3> <ul> <li><a href="https://redirect.github.com/withastro/astro/pull/14241">#14241</a> <a href="https://github.com/withastro/astro/commit/760acc86f535a48a6f5195cdc53dfc72b0dc6053"><code>760acc8</code></a> Thanks <a href="https://github.com/ematipico"><code>@ematipico</code></a>! - Fixes an issue where remote paths weren't correctly computed when generating assets</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/withastro/astro/commit/32b14f24cdd3cf2c963c97bca6099ef996f7aadf"><code>32b14f2</code></a> [ci] release (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/14244">#14244</a>)</li> <li><a href="https://github.com/withastro/astro/commit/760acc86f535a48a6f5195cdc53dfc72b0dc6053"><code>760acc8</code></a> fix(assets): fix remote path detection (<a href="https://github.com/withastro/astro/tree/HEAD/packages/astro/issues/14241">#14241</a>)</li> <li>See full diff in <a href="https://github.com/withastro/astro/commits/[email protected]/packages/astro">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/getsentry/sentry-javascript/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
size-limit report 📦
|
andreiborza
approved these changes
Aug 26, 2025
s1gr1d
reviewed
Aug 26, 2025
s1gr1d
approved these changes
Aug 26, 2025
a44a197
to
904d633
Compare
RulaKhaled
reviewed
Aug 26, 2025
904d633
to
6a332d3
Compare
RulaKhaled
approved these changes
Aug 26, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you
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.