-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
meta(changelog): Update changelog for 10.15.0 #17756
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
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
…17728) This PR adds the [no-unnecessary-type-assertion](https://typescript-eslint.io/rules/no-unnecessary-type-assertion/) eslint rule. This rule captures unneeded type assertions/conversions. E.g. the following code will be raised: ```js const thing = { name: 'string' }; // no need for !, this def. exists thing!.name // no need to cast to string, as this is already the type thing.name as string; ``` note that this also expects you to use generics where possible instead of casting types, which is nicer anyhow (e.g. `getIntegrationByName<IntegrationType>(..)` vs `getIntegrationByName(..) as IntegrationType`).
[Gitflow] Merge master into develop
We already officially only support es2020, so we may as well also use this as lib & target everywhere.
…the browser (#17714) This PR adds a long-requested feature to the browser SDKs (only!): Making an inactive span active. We do this to enable use cases where having a span only being active in the callback is not practical (see #13495 for examples). There are a couple of caveats to this feature: - This on purpose is only exported from the browser SDKs. We cannot support this in Node, due to OTel not allowing for a similar hack. Frankly, it also makes no sense in Node-based SDKs. - Calling `setActiveSpanInBrowser ` on a nested child span, will make that child span the active span as long as it is active. However, due to `parentSpanIsAlwaysRootSpan` defaulting to `true` any child span of the active child span, will still be parented to the root span. By setting `parentSpanIsAlwaysRootSpan: false`, the span hierarchy is respected and child spans are correctly parented to the active span. Note that this cannot be guaranteed to work perfectly, due to missing async context in the browser. See tests for the `parentSpanIsAlwaysRootSpan` behaviour. - A span once set active, cannot be set as inactive again. It will remain active until it is ended or until another span is set active. In the latter case, once that span ends, the initial span will be set as active again until it ends. This is reflected in the types where we by design only allow `Span` to be passed to `setActiveSpanInBrowser `. Technically, `setActiveSpanInBrowser` uses `_setSpanForScope` which I decided to re-export from core as `_INTERNAL_setSpanForScope`, similarly to how we do it with logs APIs. ### Usage This example shows one of the most frequent use cases where having an active, callback-unbound span is useful: ```js function instrumentMyRouter() { let routeSpan; on('routeStart', (from, to) => { routeSpan = Sentry.startInactiveSpan({name: `/${from} -> /${to}`}); Sentry. setActiveSpanInBrowser(rootSpan); }); // any span started in the meantime (e.g. fetch requests) will be // automatically parented to `routeSpan` on('routeEnd', () => { // automatically removes the span from the scope routeSpan.end(); }) } ``` closes #13495
## Summary This PR enhances the Hono integration by adding comprehensive handler instrumentation, error handling capabilities, and thorough test coverage. The changes build upon the basic Hono integration to provide a complete tracing and error monitoring solution. ## New Features - Handler Instrumentation: Added instrumentation for Hono handlers and middleware, providing detailed tracing capabilities - Error Handler: Implemented setupHonoErrorHandler() function to capture and report errors to Sentry with configurable error filtering - Public API: Added Hono integration to the main package exports, making it available as @sentry/node - Tracing Module: Included Hono integration in the tracing integrations index ## Bug Fixes - CJS Compatibility: Fixed an issue where applying patches failed in CommonJS environments - Type Corrections: Fixed incorrect MiddlewareHandler type definition to ensure proper TypeScript support ## Implementation Details - Instrumentation: Created HonoInstrumentation class that wraps Hono middleware handlers via class extension instead of function replacement for better compatibility - Type Definitions: Added comprehensive TypeScript type definitions vendored from Hono's official types - Constants: Defined Hono-specific attribute names for OpenTelemetry integration - CJS Compatibility: Fixed patching issues in CommonJS environments ## Testing - Integration Tests: Added comprehensive test suite covering: - ESM and CJS compatibility - Multiple HTTP methods (GET, POST, PUT, DELETE, PATCH) - Various route patterns (sync/async, different paths) - Middleware and handler instrumentation verification - Error handling scenarios - Span attribute validation ## Related Issue close #15260
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #17428 Co-authored-by: s1gr1d <[email protected]>
…yer (#17684) Enables the Lambda extension by default when using the Lambda layer --------- Co-authored-by: Francesco Gringl-Novy <[email protected]>
… values (#17751) This patch - drops any `http.request.*` timing attributes where the original value was `undefined` - sends `0` for any `http.request.*` timing attribte values that were originally `0` (i.e. no longer converts them to the `timeOrigin` absolute timestamp) --------- Co-authored-by: Abhijeet Prasad <[email protected]>
Lms24
approved these changes
Sep 24, 2025
size-limit report 📦
|
Rewording this as it is not actually correct, this is not auto-instrumented but needs to be done manually - see #17723
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
…#17743) This adds a `honoIntegration` that exposes a `shouldHandleError` function that lets users define a custom handling of capturing errors. By default, we capture exceptions with `error.status >= 500 || error.status <= 299`. It's possible to modify this behavior like this: ```js integrations: [ honoIntegration({ shouldHandleError: (err) => true; // always capture exceptions in onError }) ] ``` **Up for discussion**: The function name is the same like in express/fastify to keep it consistent. But I was also thinking about other names like `shouldHandleInOnError` or `shouldCaptureOnError` 🤔 Because it's specifically about the `onError` function. Let me know what you think. closes #17717
f89af92
to
75796c5
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.
No description provided.