inputBaggageString.split is not a function

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which package are you using?

@sentry/nextjs

SDK Version

7.1.1

Framework Version

Link to Sentry event

https://sentry.io/organizations/anyfin/issues/3338863766/

Steps to Reproduce

1. Upgrade to sentry/nextjs 7.1.1
2. Have a backend running sentry/javascript using 7.0.0
3. Trigger some requests.

Expected Result

No errors originating from sentry packgages on http calls.

Actual Result

inputBaggageString.split is not a function originating from: https://github.com/getsentry/sentry-javascript/blob/1456b9c8c62ee414fc4a6075406040fb1238a45e/packages/utils/src/baggage.ts#L74-L76

I verified this error is not triggered on the api or client routes of the nextjs package, but rather on our backend api running nextjs/javascript@7.0.0. However it only happens with requests from this specific “client” (sentry/nextjs@7.1.1).

Other sentry frontend clients connecting to the very same backend do net get this error.

Relevant section of sentry.client.config, as you can see no strange settings.

Sentry.init({
  dsn: SENTRY_DSN,
  enabled: ENVIRONMENT !== "local", // Enable only for prod envs
  // Adjust this value in production, or use tracesSampler for greater control
  tracesSampleRate: isProduction ? 0.5 : 0,
  environment: ENVIRONMENT,
  beforeBreadcrumb: excludeGraphQLFetch, // just a  small util.

[Lms24]

Hi @pepf - we just released version 7.3.0. It contains a potential fix for this reported bug. Would you mind giving this version a try? Would be very much appreciated, thanks!

[lforst]

Thank you very much for the effort!

That header is indeed a standard and we’re using to propagate trace state. My current suspicion is that there are two different baggage headers on the incoming request, causing requestOptions.headers.baggage to be an array instead of a string.

I don’t believe this is something we account for yet, as it kinda is an edge case (or rather specification violation by some service within the request chain), but we probably should. Baggage propagation in general is currently a big WIP for us.

I am aware you probably don’t care about the SDK internals and just want this fixed 😄 - I am just writing my thoughts down so the rest of the team can also pick them up.