Error events from nested iFrame do not contain source map debugID reference.

[rodolfoBee]

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 SDK are you using?

@sentry/browser

SDK Version

9.2.0

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

There is a sandbox app where the issue happens and more details on how it is configured are available in this internal ticket
See the internal comment from 28/02 with a summary of information.

Steps to Reproduce

1. Add the Browser SDK to an app with nested iFrames.
2. Use webpack plugin to upload source maps to Sentry

sentryWebpackPlugin({
authToken: SENTRY_AUTH_TOKEN,
org: <redacted>,
project: 'editor',
telemetry: false,
});

3. Throw an error in the iFrame

Expected Result

The event sent by the SDK has source maps debugIDs attached to them.

Actual Result

The event does not have the DebugID reference under debug_meta.

Because webpack rename the uploaded files, the fallback of matching abs_path to the uploaded source maps also also fails. Source maps are hosted internally with no access from outside, thus source map fetching also fails.

I can confirm that the minified file has the correct debugID, which is found in the uploaded files to Sentry:
Minified file contains:

p._sentryDebugIds[u]="9ef9d18e-3246-411d-9336-512a031cf002"
...
SENTRY_RELEASE={id:"a5fffa11f6d7735ecd9ddea4d9fd56d64f2b85e1"};

Screenshot from project settings with the uploaded file:

[lforst]

Seems like the events in question do not have debug IDs attached to them. To me this means that when the error happened, either the debug ID snippets haven't been executed yet (very unlikely / impossible), or the debug IDs do not live in the current global context from where the error was captured. This would make sense if the errors originate from an iframe since the parent window and the iframe don't share a global object (as far as I know). I think this would happen if you did something like this for example: https://stackoverflow.com/a/14041297/21967320 and capturing the exception in the onerror handler.

A way to get around the above would be to also initialize an SDK in the iframe. It could point to a different project, or the same one. Doesn't really matter as long as the right project has the right artifacts uploaded.

You can also use the legacy source map upload that does not depend on debug IDs but artifact paths: https://docs.sentry.io/platforms/javascript/sourcemaps/troubleshooting_js/legacy-uploading-methods/ It would make use of the uploadLegacySourcemaps option: https://www.npmjs.com/package/@sentry/webpack-plugin#releaseuploadlegacysourcemaps

[mbarzeev]

Thanks!

A way to get around the above would be to also initialize an SDK in the iframe. It could point to a different project, or the same one. Doesn't really matter as long as the right project has the right artifacts uploaded.

Does this have the potential of creating duplicate events in Sentry, where some are with source maps and others are without?

[lforst]

Does this have the potential of creating duplicate events in Sentry, where some are with source maps and others are without?

It depends on your setup. If you are sending over the errors to the parent window, then yes, the errors will be captured twice. You could somehow in a generic location set a property on the errors before they're being propagated upwards to the parent, and in the SDK in the parent window use beforeSend or an event processor to drop error events for errors containing that property.