Issue
I upload source maps to Sentry. Some issues did not show readable code until I fixed my upload setup, but other issues already showed readable code. I want to know how Sentry resolved source maps for a given event.
Applies To
All SaaS Customers and Self-Hosted Users
Error Monitoring
Source Maps
JavaScript SDK
Resolution
Open the event JSON and check each stack frame’s resolved_with value. That field tells you how Sentry found the artifact used to unminify that frame. Different events, and even different frames in the same event, can resolve by different methods. That is why some stack traces looked readable before your upload fix.
Open the issue, then open the event you want to inspect.
Open the event JSON (the
{}/ View JSON control).Find the stack trace frames under
exception(or underthreadswhen the event uses thread stack traces).For each frame, open
dataand readresolved_with.
Example:
"data": {
"resolved_with": "debug-id",
"symbolicated": true
}
resolved_with values and what they mean:
debug-id: Sentry matched the frame using a Debug ID. This is the recommended lookup method.url: Sentry found the file inside an artifact bundle by URL matching.index: Sentry found the artifact bundle through the artifact index / database index lookup.release: Sentry found an artifact bundle associated with the event’s release.release-old: Sentry used a legacy release file lookup.scraping: Sentry fetched the file from the web (JavaScript source scraping).unknown: Sentry did not record a known resolution method for that frame.
If readable frames show scraping or release-old, those frames did not depend on the Debug ID upload path you fixed. Frames that stayed minified often have no successful symbolication, or they needed a different artifact than the one you uploaded.
For broader troubleshooting, see Why are my source maps still not working? and How does Sentry use source maps?.