Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

chargome
Copy link
Member

No description provided.

mydea and others added 9 commits September 23, 2025 10:38
…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]>
@chargome chargome self-assigned this Sep 24, 2025
@chargome chargome requested review from a team as code owners September 24, 2025 14:06
Copy link
Contributor

github-actions bot commented Sep 24, 2025

size-limit report 📦

Path Size % Change Change
@sentry/browser 24.26 kB added added
@sentry/browser - with treeshaking flags 22.77 kB added added
@sentry/browser (incl. Tracing) 40.43 kB added added
@sentry/browser (incl. Tracing, Replay) 78.81 kB added added
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 68.48 kB added added
@sentry/browser (incl. Tracing, Replay with Canvas) 83.48 kB added added
@sentry/browser (incl. Tracing, Replay, Feedback) 95.69 kB added added
@sentry/browser (incl. Feedback) 40.97 kB added added
@sentry/browser (incl. sendFeedback) 28.91 kB added added
@sentry/browser (incl. FeedbackAsync) 33.84 kB added added
@sentry/react 25.98 kB added added
@sentry/react (incl. Tracing) 42.41 kB added added
@sentry/vue 28.78 kB added added
@sentry/vue (incl. Tracing) 42.24 kB added added
@sentry/svelte 24.29 kB added added
CDN Bundle 25.77 kB added added
CDN Bundle (incl. Tracing) 40.33 kB added added
CDN Bundle (incl. Tracing, Replay) 76.56 kB added added
CDN Bundle (incl. Tracing, Replay, Feedback) 82.05 kB added added
CDN Bundle - uncompressed 75.37 kB added added
CDN Bundle (incl. Tracing) - uncompressed 119.39 kB added added
CDN Bundle (incl. Tracing, Replay) - uncompressed 234.51 kB added added
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 247.27 kB added added
@sentry/nextjs (client) 44.42 kB added added
@sentry/sveltekit (client) 40.85 kB added added
@sentry/node-core 50.02 kB added added
@sentry/node 152.83 kB added added
@sentry/node - without tracing 91.94 kB added added
@sentry/aws-serverless 105.39 kB added added

Rewording this as it is not actually correct, this is not
auto-instrumented but needs to be done manually - see
#17723
Copy link
Contributor

github-actions bot commented Sep 24, 2025

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.

Scenario Requests/s % of Baseline Prev. Requests/s Change %
GET Baseline 9,399 - - added
GET With Sentry 1,445 15% - added
GET With Sentry (error only) 6,271 67% - added
POST Baseline 1,077 - - added
POST With Sentry 528 49% - added
POST With Sentry (error only) 1,098 102% - added
MYSQL Baseline 3,414 - - added
MYSQL With Sentry 532 16% - added
MYSQL With Sentry (error only) 2,750 81% - added

s1gr1d and others added 2 commits September 24, 2025 16:18
…#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
@chargome chargome force-pushed the prepare-release/10.15.0 branch from f89af92 to 75796c5 Compare September 24, 2025 14:34
@chargome chargome merged commit 2d54234 into master Sep 24, 2025
358 of 366 checks passed
@chargome chargome deleted the prepare-release/10.15.0 branch September 24, 2025 15:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants