debug_id is not sent as part of the event

[saarazari5]

What React Native libraries do you use?

Hermes

Are you using sentry.io or on-premise?

sentry.io (SaS)

@sentry/react-native SDK Version

5.35.0

How does your development environment look like?

OS: mac os sonoma
Node: 20.18.0
Yarn: 4.3.1
react-native: 10.2.7
hermesEnabled: true
newArchEnabled: false

Sentry.init()

using sentry-cli

Steps to Reproduce

1. follow the guide mentioned in https://docs.sentry.io/platforms/react-native/sourcemaps/uploading/hermes/
2. generate an error in your react native application.

Expected Result

event should contain debug-id in its payload.

Actual Result

no debug-id is attached to the payload unless you remove usage of deprecated ...eventProcessors.getGlobalEventProcessors() from prepareEvent.js.

also, after removing the usage mentioned, it does add the debug_id payload but bundle image does not have a reference anymore
`

[krystofwoldrich]

Hi @saarazari5,
thank you for the message,

could you share a bit more details about the issue?

---

Note that the debugIDs are only generated and added to the events in production bundles.

---

How do you check the event payload?

---

bundle image does not have a reference anymore

It that during the source maps upload? Could you share the upload command output?

[saarazari5]

Hi @saarazari5, thank you for the message,

could you share a bit more details about the issue?

Note that the debugIDs are only generated and added to the events in production bundles.

How do you check the event payload?

bundle image does not have a reference anymore

It that during the source maps upload? Could you share the upload command output?

Hi @krystofwoldrich , thank you for the quick replay, of course:

1. how does sentry separate between a production bundle and dev bundle? since it seems like for some events it did sent debug_id even though the flow was the same.

2. I checked the event payload by pressing "View Json" button on the sentry.io platform
   

3. during the source map uploads its seems like everything is correct, you can see the output in the image
   
   i also checked that the artifacts were indeed uploaded to sentry by going to the project settings.

the issue seems to be that the trace it self is not associated with the uploaded debug id , i also tried to force the mapping by proxy every access to __sentryDebugIds to return the generated debug_id, it didn't worked.

thank you!

[Niryo]

@krystofwoldrich for more context- in our react native app, we are loading multiple hermes bundles, and now we are trying to fix our bundles sourcemaps. we want to be able to reproduce it from dev, because the production cycles are too long. how can we simulate production for sentry? maybe we can patch something locally to make it work?

[krystofwoldrich]

Thank you @saarazari5 and @Niryo for the details.

---

how does sentry separate between a production bundle and dev bundle?

The Debug ID is generated for statically generated bundles, that means Debug ID is not generated when bundle is requested over the development server.

When the Debug ID is generated you should see Bundle Debug ID: <debug_id> in the Metro logs.

Together with the Debug ID comment at the end of the plain text bundle and debugId property in the source maps. The bundle should also contain a Debug ID polyfill at the top of the file. Below is unminified version of it.

sentry-react-native/packages/core/scripts/sentry-debugid-injection-snippet.js

Lines 1 to 18 in ddcabff

	// This is non minified version the debug id injection snippet used in the Metro plugin.
	var _sentryDebugIds;
	var _sentryDebugIdIdentifier;
	if (typeof _sentryDebugIds === 'undefined') {
	_sentryDebugIds = {};
	}
	try {
	var stack = new Error().stack;
	if (stack) {
	_sentryDebugIds[stack] = '__SENTRY_DEBUG_ID__';
	// eslint-disable-next-line no-unused-vars
	_sentryDebugIdIdentifier = 'sentry-dbid-__SENTRY_DEBUG_ID__';
	}
	} catch (e) {
	/**/
	}

Are _sentryDebugIds and _sentryDebugIdIdentifier globals containing any Debug IDs at runtime?

---

I checked the event payload by pressing "View Json" button on the sentry.io platform

Perfect, thank you.

[saarazari5]

Are _sentryDebugIds and _sentryDebugIdIdentifier globals containing any Debug IDs at runtime?

yes indeed, it does print the generated debug_id. when testing in production environment, for some events, the debug_id is sent inside debug_meta however sentry still don't show the unminify code correctly. its show irrelevant code:

• we checked the hermes source map locally and it worked.
• im attaching 2 links to events we crashed in a prod build. https://wix-o.sentry.io/issues/6064283726/events/5fabf05a210446e0b8debc7e67d251ad/ , https://wix-o.sentry.io/issues/6064238463/events/77965debd8b446e9a1ec7036e70ef7ad/

you can see that for those different events (which crash at different places in the code) the relevant bundle frames always leads to the same place in the bundle : store.ts.

thanks!

[Niryo]

@krystofwoldrich maybe you can take a look at this event?
we do see the debug_id in the raw json, and we do see a source map that contains this id, but for some reason sentry still wasn't able to translate the stack trace of this event

[krystofwoldrich]

Thank you @saarazari5 and @Niryo for the details,

in the example that @saarazari5 shared I see that there are 3 hermes bundles in the stack trace, but only one file is referenced in the event JSON debug images.

That seems to be the issue, we will investigate this further.

---

Just to confirm, when you symbolicate the stack trace locally, do you use 3 difference source maps one for each bundle?

[saarazari5]

Thank you @saarazari5 and @Niryo for the details,

in the example that @saarazari5 shared I see that there are 3 hermes bundles in the stack trace, but only one file is referenced in the event JSON debug images.

That seems to be the issue, we will investigate this further.

Just to confirm, when you symbolicate the stack trace locally, do you use 3 difference source maps one for each bundle?

we actually only tried to test it on one bundle, since separating our big bundle to multiple ones is a new feature, we assumed that if we will only reference one of the bundles it will show the original source code of all the frames in the stack that come from this bundle alone, as for the rest of the unreferenced bundles we assumed that if we dont generate debug id and artifacts for them it should not effect the bundle that we want to test.

[krystofwoldrich]

Thank you, yes that assumption is correct, we are currently checking why the event is not symbolicated.

[krystofwoldrich]

Do you possibly change the event.platform field or remove/change any of Sentry default integrations?

The event have not been symbolicate due to event.platfrom='other' and also the event is missing a lot of context information which the SDK send by default.

Could you share your SDK init?

[saarazari5]

Do you possibly change the event.platform field or remove/change any of Sentry default integrations?

The event have not been symbolicate due to event.platfrom='other' and also the event is missing a lot of context information which the SDK send by default.

Could you share your SDK init?

this.client.init({
dsn: WIX_ONE_APP_PROJECT_DSN,
enableNdkScopeSync: true,
environment: this.getEnvironment(),
attachScreenshot: true,
enableAutoSessionTracking: true,
tracesSampleRate: 0.3,
beforeSend: this.beforeSend.bind(this),
beforeBreadcrumb: this.beforeBreadcrumb.bind(this),
integrations: this.getIntegrations(),
beforeScreenshot: this.beforeScreenshot.bind(this),
});

im attaching the SDK init in our react native project (:

[krystofwoldrich]

Thank you @saarazari5,
is the this.client instance of ReactNativeClient?

---

If it is, why do you initialize the client directly instead of using Sentry.init function? Were you experiencing any issues with that function?

---

The Sentry.init call adds an array of default integrations, one of which (SdkInfo) sets platform='javascript' in the events, this is important for the symbolication of the events.

[krystofwoldrich]

Based on our today's conversation with @saarazari5 and @Niryo the incorrectly symbolicated frames might be cause by use of Hermes composed source map on frames from Hermes bundle with debug information (the bundle should be generated without debug information or package source map should be used).

Another possible culprit could be the source of the bundle. Load from application bundle vs load from downloads. Both variants need more investigation.