Sentry event showing all zeros for Trace ID (contexts.trace.span_id) causing processing error

[jiaxin-lin]

Is there an existing issue for this?

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

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/remix

SDK Version

10.21.0

Framework Version

remix @ 2.16.5

Link to Sentry event

https://promi-d6.sentry.io/issues/6422520377/events/d5f0306e73b64887ba085086d6f3b704/

Reproduction Example/SDK Setup

Below is our sentry init block

Sentry.init({
  dsn: "__DSN__",
  sendDefaultPii: true,
  tracesSampleRate: 0.01,
  replaysSessionSampleRate: 0.01,
  replaysOnErrorSampleRate: 1,
  attachStacktrace: true,
  // Will be replaced by Vite at build time
  environment: __SENTRY_ENVIRONMENT__,
  integrations: [
    Sentry.captureConsoleIntegration({
      levels: ["warn", "error"],
    }),
  ],
});

We capture events using Sentry.captureException. This started happening after we upgraded the sentry/remix version from v8 to v10 (we followed the upgrade guide of v8->v9 and v9->v10)

Steps to Reproduce

When sending event by calling Sentry.captureException we see that those events appeared in sentry with processing error.

Name: contexts.trace.span_id
Value: 0000000000000000
Reason: not a valid span id

Expected Result

No processing error

Actual Result

Most events have this processing error showed up saying contexts.trace.span_id is all zeros. Also Trace Details showing the Trace ID as all zeros.

Additional Context

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear[bot]]

JS-1094

[JPeer264]

Hey thanks for your issue. I just tried to set up this example and using the Sentry Wizard to set up Sentry and I am receiving actual trace and span ids.

Do you know when you started to experience the zeros as span ids?

[jiaxin-lin]

hi! It happened right after we made this change:

-    "@sentry/remix": "^8.47.0",
-    "@sentry/vite-plugin": "^2.22.6",
+    "@sentry/remix": "^10.21.0",
+    "@sentry/vite-plugin": "^4.5.0",

We did follow the upgrade guide to go from 8->9 and 9->10. This was on Oct 23, about 5 days ago.

[JPeer264]

Quite interesting. I tried to reproduce it with the exact versions as you and can't get the same result as you.

Could you try out to check out this repo and see if you can reproduce it somehow here or verify if the setup looks the same?

[jiaxin-lin]

Hi @JPeer264 thanks, when I click that link I seem to get 404, could you give permission to that maybe?

[JPeer264]

You are right my bad - I accidentally made it private. It should work now.

[JPeer264]

@jiaxin-lin have you had the chance to look at the repository?

[jiaxin-lin]

Hi! My apologies for the delay.

I checked most of the Sentry related code and almost all of them are the same, except that we've put the server side instrumentation under app/entry.server.tsx

And the exact init block for the server side is as followed app/entry.server.tsx, there's a beforeSend which is so that local development will only print to local

Sentry.init({
  enabled: __SENTRY_ENVIRONMENT__ !== "development",
  beforeSend: (event, hint) => {
    if (__SENTRY_ENVIRONMENT__ === "development") {
      console.error(
        "Caught by Sentry:",
        hint.originalException || hint.syntheticException,
        event.extra ? event.extra : "<no_extra_info>",
      );
      return null; // this drops the event and nothing will be send to sentry
    }
    return event;
  },
  dsn: "<DSN>",
  sendDefaultPii: true,
  tracesSampleRate: 0.01,
  replaysSessionSampleRate: 0.01,
  replaysOnErrorSampleRate: 1,
  attachStacktrace: true,
  // Will be replaced by Vite at build time
  environment: __SENTRY_ENVIRONMENT__,
  integrations: [
    Sentry.captureConsoleIntegration({
      levels: ["warn", "error"],
    }),
  ],
});

Here's the client side app/entry.client.tsx

Sentry.init({
  enabled: __SENTRY_ENVIRONMENT__ !== "development",
  beforeSend: (event, hint) => {
    if (__SENTRY_ENVIRONMENT__ === "development") {
      console.error(
        "Caught by Sentry:",
        hint.originalException || hint.syntheticException,
        event.extra ? event.extra : "<no_extra_info>",
      );
      return null; // this drops the event and nothing will be send to sentry
    }
    return event;
  },
  dsn: "<DSN>",
  sendDefaultPii: true,
  tracesSampleRate: 0.01,
  replaysSessionSampleRate: 0.01,
  replaysOnErrorSampleRate: 1,
  // Will be replaced by Vite at build time
  environment: __SENTRY_ENVIRONMENT__,
  attachStacktrace: true,
  integrations: [
    Sentry.browserTracingIntegration({
      useEffect,
      useLocation,
      useMatches,
    }),
    Sentry.replayIntegration(),
    Sentry.captureConsoleIntegration({
      levels: ["warn", "error"],
    }),
  ],
});

Not sure if this make a difference, but it's been like this throughout the past versions

[logaretm]

@jiaxin-lin I have a few questions that may help us debug this:

• Does it happen locally in development, in production, or both?
• Does it happen on the client, or server, or both? From the event you posted it seems to be on the server.

I'm suspecting that there is a possible bad polyfill involved, If you could also try doing this a few times in that environment and let me know what the output is:

crypto.randomUUID() // output??

[jiaxin-lin]

Hi @logaretm ,

• it only happens in production, but during development we simply just don't send event (As you can see from the init function above where

...
enabled: __SENTRY_ENVIRONMENT__ !== "development",
...

• it actually only happens on the server side (which is bulk of where our issues come from), I checked one event with a session replay and it has a trace id that looks like a proper uuid with no processing error
• I printed this on our server side and seems to get reasonable values back

2025-11-10 11:51:12.659 PST
crypto.randomUUID() fe12dc1b-eeac-4c25-ab33-e0fc2968e0b4
2025-11-10 12:26:45.389 PST
crypto.randomUUID() 27f1f519-4e4f-473e-ab95-5daedbc17867

[logaretm]

Thanks for answering, this is a bit hard to debug without a reproduction. Could you put together a repro in a public repo that has this issue?

In the meanwhile I will continue to try guessing why IDs would be generated like that on your end.

[getsantry[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀