feat(browser): Add onRequestSpanEnd hook to browser tracing integration

[logaretm]

This PR aims to address #9643 partially by introducing a onRequestSpanEnd hook to the browser integration. These changes make it easier for users to enrich tracing spans with response header data.

Example

import * as Sentry from '@sentry/browser';

Sentry.init({
  // ...
  integrations: [
    Sentry.browserTracingIntegration({
      onRequestSpanEnd(span, responseInformation) {
        span.setAttributes({
          response_type: 'JSON',
        });
      },
    }),
  ],
});

Tracing Integration and API Improvements

• Added onRequestSpanEnd callback to BrowserTracingOptions and RequestInstrumentationOptions, allowing users to access response headers when a request span ends. This enables custom span annotation based on response data.
• Updated internal request instrumentation logic to call onRequestSpanEnd for both Fetch and XHR requests, passing parsed response headers to the callback.

Utility and Refactoring

• Centralized header parsing and filtering utilities (parseXhrResponseHeaders, getFetchResponseHeaders, filterAllowedHeaders) in networkUtils.ts, and exported them for reuse across packages.
• Moved helper functions for baggage header checking, URL resolution, performance timing checks, and safe header creation to a new utils.ts file to avoid failing the file size limit lint rule.

I was hesitant to hoist up those replay utils initially but a few of them were needed to expose them on the hook callback.

Type and API Consistency

• Introduced new types RequestHookInfo and ResponseHookInfo to standardize the information passed to request span hooks, and exported them from the core package for use in integrations.

I also added the necessary tests to test out the new hook.

[linear]

JS-56 Record response headers on http client spans

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.26 kB	-	-
@sentry/browser - with treeshaking flags	22.77 kB	-	-
@sentry/browser (incl. Tracing)	40.6 kB	+0.38%	+151 B 🔺
@sentry/browser (incl. Tracing, Replay)	78.91 kB	+0.11%	+86 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	68.55 kB	+0.12%	+79 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	83.61 kB	+0.13%	+108 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	95.77 kB	+0.08%	+75 B 🔺
@sentry/browser (incl. Feedback)	40.97 kB	-	-
@sentry/browser (incl. sendFeedback)	28.91 kB	-	-
@sentry/browser (incl. FeedbackAsync)	33.84 kB	-	-
@sentry/react	25.98 kB	-	-
@sentry/react (incl. Tracing)	42.56 kB	+0.36%	+149 B 🔺
@sentry/vue	28.77 kB	-	-
@sentry/vue (incl. Tracing)	42.41 kB	+0.36%	+151 B 🔺
@sentry/svelte	24.29 kB	-	-
CDN Bundle	25.77 kB	-	-
CDN Bundle (incl. Tracing)	40.45 kB	+0.29%	+113 B 🔺
CDN Bundle (incl. Tracing, Replay)	76.65 kB	+0.09%	+66 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	82.17 kB	+0.11%	+90 B 🔺
CDN Bundle - uncompressed	75.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	119.82 kB	+0.39%	+461 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed	234.85 kB	+0.14%	+326 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	247.61 kB	+0.14%	+326 B 🔺
@sentry/nextjs (client)	44.58 kB	+0.35%	+152 B 🔺
@sentry/sveltekit (client)	41.02 kB	+0.38%	+153 B 🔺
@sentry/node-core	50.56 kB	-	-
@sentry/node	154.19 kB	-	-
@sentry/node - without tracing	92.42 kB	-	-
@sentry/aws-serverless	106.14 kB	+0.01%	+1 B 🔺

View base workflow run

[github-actions]

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,211	-	8,865	+4%
GET With Sentry	1,431	16%	1,377	+4%
GET With Sentry (error only)	6,074	66%	6,056	+0%
POST Baseline	1,214	-	1,179	+3%
POST With Sentry	521	43%	512	+2%
POST With Sentry (error only)	1,073	88%	1,060	+1%
MYSQL Baseline	3,368	-	3,285	+3%
MYSQL With Sentry	459	14%	463	-1%
MYSQL With Sentry (error only)	2,717	81%	2,718	-0%

View base workflow run

[Lms24]

Full transparency: I haven't yet looked at this in detail but I wanna share some initial thoughts:

• I think in general, it's fine to add this hook and this is somewhat in line with existing OTel (Node) instrumentation for Http. Not particularly happy with the bundle size impact but at the end of the day, this is scoped to the integration, so it is fine IMHO.
• My main "concern" is that if we expose this hook now, user will likely use it to set response headers, in whatever form they want to. Which is nice for us because PII is less of a concern BUT it also means users likely won't follow our conventions around attribute naming and structure for response headers.

=> Let's make sure we follow up with automatically setting response header attributes soon. I still need to go back and think about why we initially only scoped this only to replay. IIRC there was a concern around adding this to browserTracing by default but I can't recall what specifically that was 😅

[logaretm]

@Lms24 Thanks, I don't really have any context around this so all the information is helpful and much appreciated!

My main "concern" is that if we expose this hook now, user will likely use it to set response headers, in whatever form they want to. Which is nice for us because PII is less of a concern BUT it also means users likely won't follow...

I agree, but doesn't the same risk already exist with onRequestSpanStart? and at the moment some users seem to be rolling their own manual instrumentation to get around it, or that's the idea they are getting:

From the issue:

As an alternative it seems we could wrap all of our requests in spans to manually instrument post-processing of spans (docs.sentry.io/platforms/javascript/tracing/instrumentation/requests-module), but as far as I can tell this is entirely independent of tracing and would require us to roll our own behavior for things like sampling.

I don't have opinions on this, so happy to discuss it further. The main issue seems to be auto instrumentation of response headers rather than providing a hook for it, so this is just offering users an escape hatch at the moment.

Let's make sure we follow up with automatically setting response header attributes soon...

Oh yea, I was thinking whether to tackle this but decided not to until someone takes a look at this and gives me more context, given that there are PII concerns and Replay relationship.